feat(settings): wire up the password-free passkey opt-in

[vpomerleau]

Because

• A desktop browser sign-in that needs encryption keys (Sync, for example) still requires a password after a PRF-capable passkey until a wrap is stored, and sign-in is the one place the user has everything needed to store one.
• The proof minted at sign-in lives ten minutes and the password step can outlast it.
• Behind the passkeyPasswordlessSyncEnabled flag; nothing renders when it is off.

This pull request

• Requests the passkey scope on desktop Sync sign-ins and holds the PRF output, proof and kB in SensitiveDataClient.
• Skips the offer when the account has no password yet, the passkey already has a wrap, the client is mobile, or the service is not Sync.
• Routes eligible sign-ins to /inline_passwordless_sync_setup in place of the browser's post-sign-in landing page.
• Adds the opt-in container: stores the wrap, lands in Settings with a success or error alert, and zeroes the held material on every exit.
• Steps up with the passkey for a fresh proof when the sign-in one has expired, then submits the same envelope again.
• POST /passkey/wraps replaces a stored wrap that predates keysChangedAt instead of refusing it, deleting only the row it read; the opt-in treats a remaining conflict as already stored.

Issue that this pull request solves

Closes: FXA-13151

Checklist

Put an x in the boxes that apply

• My commit is GPG signed.
• If applicable, I have modified or added tests which pass locally.
• I have added necessary documentation (if appropriate).
• I have verified that my changes render correctly in RTL (if appropriate).
• I have manually reviewed all AI generated code.

How to review (Optional)

• Key files/areas to focus on: lib/passkeys/signin-flow.ts (eligibility and stash), lib/passkeys/wrap/creation.ts (store and step-up retry), pages/InlinePasswordlessSyncSetup/container.tsx (exit paths), passkey.service.ts storePasskeyWrap (stale replacement).
• Suggested review order:
• Risky or complex parts: key material lives only in SensitiveDataClient and is zeroed on every exit, including unmount and a ceremony or navigation that finishes after the page is gone. The retry re-POSTs the already-sealed envelope, so it needs no kB. A wrap conflict on this surface can only be a live wrap from the same key epoch, hence success. The stale replacement is a read, then a delete pinned to that row's createdAt, then an insert; zero rows deleted, or a non-finite keysChangedAt, is a conflict.

Screenshots (Optional)

Please attach the screenshots of the changes made in case of change in user interface.

Other information (Optional)

• Non-Sync Firefox services that require keys (Relay, VPN on pre-147 desktop) are not offered the opt-in; their landing pages are unchanged pending product and RP review.
• The CMS syncHidePromoAfterLogin flag also withdraws this offer. Whether it should is an open product question.
• The page still uses the Sync clouds illustration.
• The wrap probe at sign-in treats errno 202 and 114 as "withhold the offer" without a Sentry report, so a client-first flag rollout stays quiet.
• The passwordless sign-in branch stacks on this one as feat(settings): sign in to Sync with a PRF passkey and no password #21224.

[bcolsson]

Would it be possible to keep the old string IDs for the duplicate strings to reduce the churn of having to retranslate these?

[vpomerleau]

Would it be possible to keep the old string IDs for the duplicate strings to reduce the churn of having to retranslate these?

Sorry about that! Reverted now.

[Copilot]

🔵 Needs a closer look

It introduces cross-surface auth-flow changes involving sensitive key material handling and server-side wrap replacement semantics that warrant final human review for security and correctness.

Review details

• Files reviewed: 32/32 changed files
• Comments generated: 0 new
• Review effort level: Lite

[vpomerleau]

The success and error message strings are under discussion and will likely change before this is merged

[nshirley]

Just a few more questions! 🙂

[nshirley]

Kind of thinking out loud here. I don't know exactly what the mechanism might look like (took a shot at it below), but I see this state is having to be carefully managed across several places and I wonder if there's a way to centralize the management of it; hoisting the guard to clear it to the app index?

// something like this in app/index to prevent it from leaking out
const WRAP_MATERIAL_ROUTES = ['/signin_passkey_fallback', '/inline_passwordless_sync_setup'];

useEffect(() => {
  if (!WRAP_MATERIAL_ROUTES.some((r) => location.pathname.startsWith(r))) {
    sensitiveDataClient.clearPasskeyWrapData();
  }
}, [location.pathname, sensitiveDataClient]);

I also could be over-thinking this, but curious what you think?

[vpomerleau]

I like this. Updated.