Replace OAuth on-ramps with passkey sign-in: zero registration, zero servers

Owner decision: static only, and no per-site provider registration --
which every OAuth path requires (and GitHub/Facebook additionally require
a server). Both on-ramp implementations (service handshake, serverless
Google Drive) are removed the day they shipped; centralized-onramps.md
stays on the record as the analysis of why, superseded by
passkey-login.md.

The passkey rail: a WebAuthn PRF-capable passkey (synced for most users
by Google Password Manager or iCloud Keychain) deterministically derives
the login name and password of a standard capsule account -- passkey.ts
holds the derivation behind a FROZEN v1 known-answer contract with the
same standing rule as knownAnswer.test.ts. The ordinary password flows
do everything else; nothing is stored outside the user's authenticator,
and the rail needs no network of its own.

Flow is idempotent by construction: sign-in against a passkey with no
account routes into setup with the derived credential
(AccountNotFoundError); setup against an existing account signs in
(AccountAlreadyExistsError). Fresh identity or §SF10 nsec import at
setup; Tier B2 phrase card retained ('your account stays yours even if
you lose your passkey'); rotation is the graduation step and says so.

Pins updated: passkey row with honest custody label inside the menu,
OAuth actions provably absent, element still network-free. 11 passkey
tests incl. the frozen vectors; menu and screens verified in Chrome.

Co-Authored-By: Claude Fable 5 <[email protected]>

docs/login-methods.md

@@ -59,9 +59,11 @@ never needs a login UI other than BitLogin, and BitLogin's security story —
 *no method ever puts a root key on the page* — holds across every method it
 offers (§LM6).
 
-A fourth family of methods — clearly labeled centralized OAuth on-ramps
-(Google, GitHub, …) that manage the credential while the account stays a
-standard capsule account — is designed separately in
+A fourth method — passkey sign-in, where a WebAuthn PRF-capable passkey
+(synced by the user's Google/Apple account) deterministically derives the
+credential of a standard capsule account with zero site setup and zero
+servers — is designed in [`passkey-login.md`](./passkey-login.md). The OAuth
+on-ramps considered before it are superseded and kept on the record in
 [`centralized-onramps.md`](./centralized-onramps.md).
 
 # LM3. Architecture: one facade, pluggable signers