feat(passkey): let a user finish registration without a passkey

[Bccorb]

Last of four PRs. This is the actual feature.

Draft: blocked on the chain below. Verified locally against a local build of the types package.

1. feat(system-config): add a public system config response contract seamless-auth-types#23 (contract)
2. feat(system-config): serve the public system config unauthenticated seamless-auth-api#136 (endpoint)
3. feat(system-config): proxy the public system config from both adapters seamless-auth-server#143 (both adapters proxy it)
4. this

The problem

Registration ended on a screen with exactly one control: "Register Passkey". No skip, no back. And if passkeySupported was false it rendered "Passkeys are not supported on this device." and nothing else, on a screen the user could not leave.

The session already exists by the time that screen renders, since the OTP step that leads there establishes it. EmailRegistration already finishes without a passkey when the device does not support one, using exactly await refreshSession(); navigate('/'). So leaving without a passkey was always a legitimate way to finish, just not one the UI offered.

The gate

The skip only appears when a method other than passkey is enabled. With passkey as the only method, skipping would leave a user unable to sign back into the account they just created, so the control is not rendered at all.

Unknown counts as unsafe. useLoginMethods returns null rather than [] when the read fails or is in flight, and hasNonPasskeyLoginMethod(null) is false. A network blip cannot produce a skip button that strands someone.

The unsupported-device branch now distinguishes the two cases: a way forward when one exists, and a clear statement that the application requires a passkey when it does not.

Also fixed

Login started from a hardcoded ['passkey', 'magic_link', 'phone_otp'], which does not match the auth server's SYSTEM_CONFIG_DEFAULTS.login_methods = ['passkey', 'magic_link']. It advertised phone OTP on instances that never enabled it. It now uses the methods the instance reports, with a narrower fallback matching the server. The login response stays authoritative when it carries methods of its own.

Scope I backed out

I briefly routed AuthFallbackOptions' internal default through the same constant. That narrowed its behaviour and broke two of its tests, which were right to fail: that component is the last step of a fallback flow and should stay permissive about handlers a caller explicitly wired up. Reverted to its original default, with only the prop type widened to accept null.

Tests

290 passing, up from 279. Eight new:

• skip appears with another method enabled, and finishes without calling registerPasskey
• no skip when passkey is the only method
• no skip while methods are unknown
• unsupported device gets a way forward when one exists, and is told plainly when it does not
• useLoginMethods returns the reported methods, and leaves them null on both a failed read and an empty list
• hasNonPasskeyLoginMethod across all four inputs

The existing unsupported-state test was updated: it asserted the exact dead-end copy this PR removes.

hasNonPasskeyLoginMethod is deliberately not mocked in the view tests. It encodes the rule that decides whether a skip is safe, so mocking it would test nothing.

Verification

npm run typecheck, npm test (290 passing), npm run lint, npm run format:check, npm run build all clean.