Backports from frontend-base

[arbrandes]

Description

This is a list of commits that should be considered for backporting from the frontend-base branch:

• TPA query fires unconditionally in ProgressiveProfiling.jsx — fires even when registrationEmbedded is false. Fixed in 86b4ea7.
• setThirdPartyAuthContextBegin called on every data sync in LoginPage.jsx — causes a flash of PENDING state when TPA data is already cached. Fixed in 8dcf552.
• payload not included in TPA query key — payload changes with same pageId would serve stale data. Fixed in e52d3d8.
• staleTime missing from TPA context query — unnecessary background refetches between login/register tabs. Added in bb3ab6c.
• PASSWORD_RESET_ERROR dead code in ResetPasswordPage.jsx — no code path sets status to this value. Removed in fc40952.
• Duplicate RedirectLogistration in ProgressiveProfiling.jsx — redundant block gated on shouldRedirect && welcomePageContext.nextUrl has existed since PR feat: param based redirection #993; broader shouldRedirect block covers it. Fixed in 1733f6e.
• Duplicate should show single sign on provider button test in ThirdPartyAuth.test.jsx. Fixed in 444e825.
• mockResolvedValueOnce({ success: true }) in progressive-profiling/data/apiHook.test.ts — patchAccount returns void; should be undefined.
• ResetPasswordPayload.params type — 444e825 widens to Record<string, string | boolean>; master still has Record<string, string>. Test payloads use boolean is_account_recovery in both, but api.ts converts it to a string. Worth tracing call sites to confirm the correct type.

Low priority

• Registration test cookie checks — master's should call internal state setters on successful registration and duplicate-named test both use await waitFor(() => expect(document.cookie).toMatch(...)) to verify the cookie. The frontend-base branch drops the cookie assertion from these tests because cookie-setting is a separate useEffect concern, already covered by the dedicated should check user retention cookie test. Cleaner separation, no coverage loss. Part of cb3ad5c.
• PasswordField decoupled from RegisterContext via props — master's PasswordField reaches directly into RegisterContext (via useRegisterContext()) for setValidationsSuccess, setValidationsFailure, validationApiRateLimited, and clearRegistrationBackendError. The frontend-base branch passes these as optional props from RegistrationPage instead, so PasswordField has no context dependency. Login and reset-password flows rely on noop defaults. Done in c0cf462.