Passkeys: login

[ParallelEntrepreneur]

Part of #1.

Blocked by: #13 (Passkeys: registration)

Problem. Passkey login must work both with a known user (email first) and discoverable credentials (no email, the authenticator picks), and must update the signature counter to detect cloned authenticators.

Proposed approach.

• POST /passkeys/login/options with an optional email: returns PublicKeyCredentialRequestOptions with a fresh challenge row; when an email is given, allowCredentials lists that user's passkeys; when not, it is empty and the authenticator offers discoverable credentials.
• POST /passkeys/login/verify: consumes the challenge, looks up the credential by id, verifies the assertion signature over authenticatorData || sha256(clientDataJSON) with the stored COSE key, checks userPresent, checks the sign count is greater than stored when both are non-zero (a regression marks the credential suspect and refuses), stores the new count, and issues a session.
• Conditional UI (autofill) support: the options endpoint tolerates an empty request so the browser can pre-fetch.

Acceptance criteria

• Assertion verification tested with fixtures for P-256, RSA and Ed25519 keys
• Sign-count regression detected and refused; tested
• Unknown credential id and consumed challenge both fail without revealing which
• Manual run in a real browser including the discoverable-credential path

[ParallelEntrepreneur]

Landed in #30 (c6b2eed), together with #13.

All four acceptance boxes except the last:

• Assertion verification tested for P-256, RSA and Ed25519. every_algorithm_a_real_passkey_can_present_verifies runs the full HTTP round trip for each. A COSE key we cannot build a verifier for is refused at registration rather than stored and failed at every later login.
• Sign-count regression detected and refused. It also marks the credential, so the next attempt is refused before verification, and the browser stops being offered it. The review caught a serious bug in the first version of this: the counter was compared before the signature, so a forged assertion with garbage bytes could permanently disable any stranger's passkey. The order is now the spec's (7.2 step 21 then 22) and a_forged_assertion_cannot_disable_someone_elses_passkey is the attack as a test. The counter rule also follows the spec now: when either value is non-zero the presented one must be greater, so a zero after a non-zero no longer switches detection off for good.
• Unknown credential id and consumed challenge both fail without revealing which. every_way_to_fail_answers_identically asserts the four refusals are identical apart from the request id.
• Conditional UI: login/options takes an empty body, so a browser can pre-fetch before the person has typed anything.

Still open, and the reason #13 stays worth revisiting: the manual run in a real browser. The tests mint ceremonies with a software authenticator, which covers all three algorithms and every negative case but has never met hardware. The review found one thing that would have failed there immediately — Chrome asks a security key for credProtect under exactly the options this module sends, and the first version treated the resulting extension bytes as corruption. That is fixed and tested, but it is a reminder that only real hardware closes this properly.