docs(auth): passkey (WebAuthn) login spec (HT-75) - #88

Fixes all findings from the first review round (5 major/6 minor lead-tier,
1 high/1 medium Codex):

- Enrollment hardening: passkey registration (options + verify) now
  requires fresh step-up re-authentication (existing password or an
  existing passkey, bound to the session, 5-minute TTL) plus a best-effort
  "new passkey added" notification email — and §10 states plainly that
  sessions are stateless HMAC cookies with no revocation, which is why
  both mitigations exist.
- Conditional-mediation staleness: proactive challenge re-mint below the
  TTL, plus a reactive challenge_expired retry-once fallback for
  backgrounded-tab timer throttling.
- The challenge token's ceremony discriminator is now enforced at both
  the application and database layers, not just recorded.
- Counter/clone-detection policy reversed from log-only to a two-tier
  exempt/reject-and-alert policy, routed to the existing HT-44
  /internal/health alertable surface via a new sign_count_regression_at
  column — the zero-counter exemption already filters out the
  synced-passkey population the old justification worried about, so a
  regression on the remaining population is a high-quality signal.
- The challenge-row volume claim was false (rows mint on every login-page
  mount, not just login attempts) — corrected, with an opportunistic
  purge-on-mint fix, no cron.
- RP ID dev carve-out narrowed to localhost only, not loopback IP
  literals (WebAuthn requires a domain-form hostname).
- Worked example fixed (inbox.resonantiq.app, the UI's own host, not
  desk.resonantiq.app, the engine's).
- agents-and-auth.md §3.2 amended: it previously anticipated passkey
  identities living in agent_auth_identities; corrected to point at this
  spec's dedicated webauthn_credentials table instead, with the
  cardinality argument for that choice dropped (it was never valid) and
  the two arguments that actually hold kept.
- Added: userHandle-vs-agent_id consistency check at authentication
  verify, a generic 409 for a credential_id already claimed by a
  different Agent, api-types.ts's descriptor-kind widening, and a
  rollout warning that changing HELPTHREAD_UI_BASE_URL's host silently
  invalidates every existing passkey.

Still spec only — no code, no migrations.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Three fixes from CodeRabbit's first pass on the HT-75 passkey spec:

- agents-and-auth.md §3.2's HT-75 amendment cited "an Agent holding many
  credentials" as a reason passkeys need their own table — that's the
  cardinality argument passkeys.md §2.1 explicitly rejects (nothing in
  agent_auth_identities restricts provider='passkey' to one row). Fixed
  to cite only the two reasons that hold: mutable per-use state and the
  incompatible column shape.
- passkeys.md's registration/verify endpoint declared name? (optional)
  while webauthn_credentials.name is NOT NULL, with nothing stating what
  happens on omission. Reconciled: an omitted/blank name gets a
  server-computed default ("Passkey — {date}") before insertion, stated
  in both the endpoint table and §6.1's prose.
- §6.2's counter check and its persistence were described as sequential
  steps against the same row read used for cryptographic verification —
  a real race: two concurrent valid authentications could both pass
  against a stale counter, and the later write (even with the lower
  counter) could silently overwrite a higher one already stored,
  undermining §8's Tier 2 policy. Fixed: the counter compare-and-set now
  happens under SELECT ... FOR UPDATE inside one transaction, re-reading
  the row fresh after cryptographic verification rather than reusing the
  earlier read.

Still spec only — no code, no migrations.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>