feat(experience,phrases): add pinned password and primary code step-up screens

[wangsijie]

Summary

Stacked on #9589 (the /step-up route tree), which is stacked on #9582 (submitStepUp). Implements LOG-14115: the pinned-user first-factor pages of the step-up route tree, the two screens #9589 left navigating to a 404.

API

apis/experience/step-up.ts gains the two verification calls, next to the sendStepUpVerificationCode() it already had:

• verifyStepUpPassword(password) — POST /verification/password { password }. No identifier, raw or masked, rides along: Core verifies against the pinned subject's credential.
• verifyStepUpVerificationCode({ type, code, verificationId }) — POST /verification/verification-code/verify { identifier: { type }, code, verificationId }. As when sending, only the type travels; Core reads the value it challenged from the verification record.

Both complete through the existing identifyAndSubmitInteraction({ verificationId }), so the identification phase's public contract is unchanged and the existing conflict guard rejects a record that resolves to another account.

Screens

• /step-up/password renders a password form that is the password field of the sign-in form and nothing else: no identifier to show or switch, and no forgot-password link, since the mode rejects the event switch it would start. There is no captcha either — nothing on this page creates an interaction.
• /step-up/verification-code/:type renders StepUpCodeVerification, modeled on MfaCodeVerification (the existing value-less code container) rather than on containers/VerificationCode, whose props, flow-keyed hooks and switch links are all built around a raw identifier. The header shows only the masked identifier from the server context, and the resend goes through the same pinned variant, renewing the stored verification ID so a refresh verifies against the code that was actually sent last.
• Both pages read the authenticationContext the guard loaded and render the invalid-session page when Core no longer offers that method, so a stale link or a method removed mid-flow is not a form to fill in.

Route shape

The code page takes the identifier type as a path segment, /step-up/verification-code/:type, rather than the bare /step-up/verification-code of the design's route table. With both primary code methods offered, nothing else on the page distinguishes them once location.state is off the table, and the design's own "no location.state dependency" rule is what makes the path the right place for it: a refresh lands on the same method. getStepUpVerificationCodeRoute(type) builds it, and the method list navigates through it.

Error handling

Each screen composes three sets, in this order:

• Its own inline errors — a wrong password, a wrong or expired code — shown on the form rather than toasted, as on the sign-in pages.
• useSubmitInteractionErrorHandler(SignIn), so a sign-in with requested ACR continues from the same pages into MFA verification, a mandatory profile, or MFA enrollment. These pages are where session.step_up.require_verification lands, through the landing that feat(experience,phrases): add the step-up route tree with method selection and guard #9589 navigates it to.
• useStepUpErrorHandler, which wins on a conflict: a session that is gone, a subject mismatch, a route the mode forbids, and a submission that does not yet satisfy the selected class (back to the method list, which refetches the authoritative context — the path a step-up to mfa takes after this first factor).

Sentinel lockout errors are untouched and keep their existing toast, so step-up and sign-in surface a lockout identically.

Adds step_up.enter_password_description and step_up.enter_verification_code_description in all 21 Experience locales.

Testing

Unit tests

• apis/experience/step-up.test.ts: the exact payload of each call (pinned strictly: no identifier value on either), that the record the verify call returns is the one that identifies the subject, and that a rejected password or code neither identifies nor submits.
• pages/StepUp/Password/index.test.tsx: the form renders only when Core still offers the password, the absent forgot-password and switching affordances, the submitted payload, the empty-password guard, the inline invalid-credentials message, and the composed handler set.
• pages/StepUp/VerificationCode/index.test.tsx: each identifier type with the verification ID the send stored and the masked identifier from the server context, an identifier type that takes no code, and the invalid-session page when the context is gone, the method is no longer offered, or no code was sent for that identifier.
• containers/StepUpCodeVerification/index.test.tsx: verify and resend by identifier type only, verifying against the renewed record after a resend, the incomplete-code guard, and both failure paths through the step-up handlers.
• containers/StepUpMethodList/index.test.tsx: updated for the typed code route.

The whole Experience suite passes (639 tests), together with tsc, ESLint and Stylelint for the package and the two phrases packages.

Not exercised: the flow in a browser against a running Core.

Checklist

• .changeset (dev feature; M8 adds the changeset)
• unit tests
• integration tests (LOG-14119)

🤖 Generated with Claude Code

https://claude.ai/code/session_01FFx5WPS3gkEZc5jWEbX7J1

---

Generated by Claude Code