[Bccorb]

Builds the v0.20 "never locked out" features in the client SDK and the React prebuilt UI, against the auth API's docs/account-recovery.md and adapter manifest on main.

Client (@seamless-auth/client)

• Recovery codes: getRecoveryCodeStatus(), generateRecoveryCodes() (a 403 step_up_required when replacing a set is recognized by isStepUpRequired(); generateRecoveryCodesWithStepUp() runs the step-up and retries), redeemRecoveryCode(code).
• Account recovery: startAccountRecovery(channel), verifyAccountRecovery(code), getAccountRecoveryStatus(), completeAccountRecovery(), cancelAccountRecovery(cancelToken), listAccountRecoveryRequests(), cancelAccountRecoveryRequest(id).
• Recovery sessions: redeem and complete set isRecoverySession() and the session state's recoverySession; session actions redeemRecoveryCode and completeAccountRecovery. After a passkey registration or TOTP enrollment from a recovery session the client calls POST /refresh (new Transport.refresh()), so the access token drops the recovery claim.
• Bearer ROUTE_RULES for every recovery route, mirroring the manifest credentials (preAuth, access, none), with issue on redeem and complete.
• Shared flows for every binding: loadRecoveryOptions, recoveryCancelTokenFromHash, cancelRecoveryFromLink, recoveryErrorMessage, recoveryCodesText, passkeyKind, passkeyDisplayName, plus getRecoveryErrorCode() and isEnrollmentRequired().
• Passkeys: list, rename and delete already existed (credentials, updateCredential, deleteCredential on /users/credentials), so nothing new was added there.

React (@seamless-auth/react)

#185 recovery codes

• /recovery-codes, shown after a passkey is enrolled: generates and shows a first set (or a new one once every code is spent), copy and download, and a "saved them" confirmation before continuing.
• "Use a recovery code" on sign-in (/recovery-code), which redeems the code and sends the user to enroll a passkey.
• RecoveryCodeSettings to regenerate from account settings, stepping up with the passkey when the API asks.

#186 passkey management

• PasskeyManagement: list with name, kind (synced, device, security key) and last used; rename; delete with confirmation (stronger warning for the last one); add another; a nudge towards a second passkey when only one exists.

#208 self-service recovery

• /recovery/cancel: reads the token from the fragment, drops it from the address bar, posts it, and shows the outcome.
• /account-recovery from sign-in, offered only when the public config reports accountRecovery: channel, code, the waiting period (completesAt), "check again", then completion. Handles 503 recovery_notice_failed, 403 account_recovery_disabled, a wrong code and a lapsed pre-auth token.
• A recovery session goes straight to /register-passkey, which cannot be skipped in that state.
• RecoveryRequests: open requests with cancel in settings. AccountSecurity renders all three settings sections.

Also: @seamless-auth/types bumped to ^0.31.0 (the changeset for that ships with #210), Svelte's session class exposes the new actions, and the client, React and React Native READMEs document it all.

Checks

npm run lint              pass
npm run typecheck         pass (all six packages)
npm run format:check      All matched files use Prettier code style!
npm test                  Jest: 52 suites, 704 tests passed; Vitest (svelte): 42 passed
npm run build             pass
npm run check-npm-build   pass
npm run coverage          All files 94.13 stmts / 87.93 branches / 88.66 funcs / 95.17 lines
npm run check:types-current  @seamless-auth/types "^0.31.0" is current (latest 0.31.0)
npx commitlint --from origin/main  pass

Contract notes

• @seamless-auth/types 0.31.0 does not publish the GET /recovery/requests list shape, or the recovery error codes. AccountRecoveryRequest is composed from AccountRecoveryStatus plus id and channel, and RecoveryErrorCode is a local union.
• GET /users/me does not say whether the session is a recovery session, so the client only knows it in memory. After a reload it cannot route a half-recovered user to enrollment or refresh after enrolling (the adapter's silent refresh fixes the claim once the access token expires).

Needs an auth API with account recovery (v0.20) and a server adapter that proxies its manifest routes, including POST /auth/refresh.

Closes #185
Closes #186
Closes #208