feat(svelte): authenticator app (TOTP) enrollment and sign-in screens #216

The prebuilt UI has no authenticator app (TOTP) screens, though the auth API supports TOTP enrollment, sign-in and step-up. With v0.20 this matters more:

• A recovery session (recovery: true, from account recovery or a recovery code) can only lift its restriction by enrolling a passkey or TOTP. On a device without passkey support, the prebuilt UI currently has no way forward (see feat: recovery codes, self-service account recovery and passkey management #211).
• A TOTP credential is a strong factor for break-glass admins, and it is the step-up fallback when no passkey is present.

API routes (through the adapter at /auth):

• GET /totp/status
• POST /totp/enroll/start, which returns { secret, otpauthUrl }
• POST /totp/enroll/verify
• POST /totp/verify-login (pre-auth)
• POST /totp/verify-mfa (step-up)
• POST /totp/disable

The client already has totpStatus, enrollment start/verify, disable and verifyStepUpWithTotp. Sign-in with TOTP (/totp/verify-login) needs a client method, shared by every binding.

Done when

• Enrollment screen:
  • Shows the otpauthUrl as a QR code, with the secret for manual entry and a copy button.
  • Verifies the first code.
  • Shows a clear success state, then continues to recovery codes if the account has none (same as after passkey enrollment).
  • Choose a QR approach that adds no heavy dependency, or render the URL as text with a link and file the QR follow-up.
• Recovery sessions: when the device cannot register a passkey, the enrollment step offers "Use an authenticator app". After a successful verify the client refreshes, so the session drops recovery: true.
• Sign-in: when /login offers totp (or the account has TOTP and passkeys are unavailable), a code entry screen calls /totp/verify-login. It handles wrong codes, a reused code (the API refuses a counter it has seen) and lockout.
• Step-up: where the binding prompts for step-up (for example regenerating recovery codes), offer TOTP when the account has it.
• Settings: status, enroll and disable (disable needs a fresh step-up).
• Tests for each screen and state. UI copy in the binding's existing style, with no em dashes.

Where: packages/svelte screens and routes. Depends on the client method from #213.