React SDK cannot request a security key at enrollment

[Bccorb]

Part of #155. Session 1. Split out of #156.

Problem

#156 made the API able to offer roaming authenticators, and added
?attachment=platform / ?attachment=cross-platform on
GET /webauthn/register/start. Nothing in the client can ask for it yet.

seamless-auth-react builds that query string from a PRF-shaped input
(buildRegisterStartPath in src/client/createSeamlessAuthClient.ts, which sets
only requestPrf and requirePrf), so the attachment parameter is not
reachable through the SDK. Registration also goes straight to
startRegistration({ optionsJSON }) with no branch point where a user could say
"I want to use a security key instead."

The default now offers both kinds in the browser picker, so this is not blocking
enrolment. What is missing is the deliberate path: an agency handing someone an
issued key wants that person taken straight to it, not left to find it in a
picker.

Why it matters

This is the client half of the hard cases in Appendix B of the migration
runbook: the issued key on a lanyard, and per-person roaming keys on a shared
front-desk workstation. Staff being walked through enrolment by a help desk need
an obvious path, not a browser dialog they have to interpret.

What to do

The work lands in seamless-auth-react, not in this repository.

• Widen the registration input so a caller can request an attachment, and thread
  it into the register/start query
• Offer a visible "use a security key instead" path in the bundled enrolment UI
• Render the 400 the API returns for an unrecognised attachment
• Keep the default unset so the picker still offers both kinds

Acceptance

• A caller can drive a security-key enrolment through the SDK without hand
  building the URL
• The default enrolment path is unchanged
• Covered by tests in the SDK repository

Freeze status

Exception 4. Blocked on nothing: the API side shipped in #156.

[Bccorb]

The client half of this is done and merged: fells-code/seamless-auth-react#137,
tracked there as fells-code/seamless-auth-react#136.

All four items under "What to do" are covered:

• RegisterPasskeyOptions takes an optional attachment, threaded into the
  register/start query by buildRegisterStartPath
• The bundled enrolment view offers a "Use a security key instead" control that
  requests cross-platform
• attachment_not_allowed is read by getPasskeyPolicyErrorCode(), and the
  enrolment view renders a specific message for it rather than a generic failure
• Omitting the option sends no query parameter, so
  authenticator_policy.attachment stays in charge and the default picker still
  offers both kinds. There is a test pinning that specifically.

The SDK types the option as Exclude<AuthenticatorAttachmentPolicy, 'any'>,
derived from the config policy in @seamless-auth/types, since the request-side
WebAuthnAuthenticatorAttachmentSchema lives here rather than in the types
package. If a request-side union is ever published there, the SDK should move
onto it.

One thing worth splitting out

"Render the 400 the API returns for an unrecognised attachment" turns out to be
two different responses, and the SDK can only render one of them.

A recognised value that conflicts with a pinned policy is refused in
registerWebAuthn with { "error": "attachment_not_allowed" }, which is what
the SDK now reads.

An unrecognised value never reaches the controller. It fails
WebAuthnRegisterStartQuerySchema in defineRoute, where query.parse throws
and the catch answers res.status(400).json(error) with the Zod error itself.
That body carries no error code, so there is nothing stable for a client to
branch on, and it does not match the 400: ErrorSchema the route declares for
itself. Nothing logs the mismatch either: validate runs before the handler
that installs the response-schema check, so that check is never in place for
this response.

Not a problem for a TypeScript caller, since the SDK's union makes an
unrecognised value unrepresentable, and not something I would fix from the
client side.

Now tracked separately as #222, with the serialized body confirmed against the
pinned zod@4.3.6 rather than read off the source. It turns out to be worse
than a missing code: with no error key, the SDK's extractMessage falls back
to message, so error.message becomes the whole escaped JSON blob.

With the client work merged, this can be closed unless the unrecognised-value
case above should stay open against it.

[Bccorb]

Closing: the client work is merged as fells-code/seamless-auth-react#137, covering all four items under "What to do" and both acceptance criteria that land in the SDK.

The one loose end from this issue, the unrecognised-attachment 400, is not a client concern and is tracked separately as #222.