identity: implement ADR 0008 — CipherBox issues the Core Kit identity token

[FSM1]

Umbrella for implementing ADR 0008 — CipherBox issues the Core Kit identity token, and wallet login is first-class on web (FSM1/cipher-box-next#64). The blueprint statement of it is #1255.

Work is tracked as sub-issues of this one — this body carries no checkbox list.

Correction to this issue's original framing

This issue was filed asserting that v2 had regressed from v1 by accident. That is wrong, and the correction matters for scoping.

A CipherBox login has two authentications:

1. Unlocking the Core Kit — an identity provider vouches for the person; the Core Kit returns the TSS key the login secret derives from.
2. Authenticating to the API — the engine signs a challenge with the derived identity key.

(2) was decided — FSM1/cipher-box-next#28 D5, restated in blueprint/engine.md and blueprint/api.md. It is correct and nothing here changes it.

(1) was never decided. v2 built it as Web3Auth's hosted OAuth in the client wiring; v1 had CipherBox mint a JWT against a custom verifier. The account model cannot distinguish them, because the Core Kit yields the same secp256k1 key whichever provider vouched — so blueprint/api.md's "Account = the Web3Auth-derived identity key" holds under both, and the issuer was chosen rather than decided.

ADR 0008 decides it. That makes the change far smaller than "restore v1": the account model, challenge-signature login, the engine-held token lifecycle, and the CredentialStore split all stand.

What the ADR decides

• D1 — CipherBox issues the identity token the Core Kit consumes, via a custom verifier over the API's own JWKS. Passwordless email returns to the API. Google's OAuth client ID is the provider's, distinct from the Web3Auth project client ID.
• D2 — Wallet is a first-class first login, web only. This amends Decide: v-next feature set cipher-box-next#5. It is web-only because the Tauri webview reaches no wallet — a platform property, not a deferred feature. v1 wrote that desktop path and never wired it.
• D3 — One host-agnostic orchestration package; credential collection injected per host. The boundary sits at credential collection, one step earlier than v1 drew it at the bearer token, which is where v1's two hosts drifted.

Why the boundary moved

v1 shared no login code: roughly 3,600 lines in apps/web against 2,400 in apps/desktop, implementing the same flows twice, and it drifted measurably — MAINNET against DEVNET for one environment, a device-factor recovery branch on one host only, viem/siwe against a hand-concatenated EIP-4361 string, and an email-OTP failure where one half read a compile-time API URL and the other a runtime one.

The Core Kit itself ran correctly in the Tauri webview, so it is not the obstacle. Exactly one step cannot be shared: Google credential collection, because GIS does not run in that webview and a packaged Tauri origin cannot satisfy the redirect_uri its fallback needs.

Sequencing

#1256 is independent of the ADR and should land first — it is a live defect that breaks every Google sign-in today, whatever the identity architecture turns out to be.

The rest are provisional on FSM1/cipher-box-next#64 being accepted, and carry dependency edges rather than an order in prose.

Largest cost, stated up front

apps/desktop/frontend is a 43-line static HTML file with no bundler, no TypeScript and no dependencies, and src-tauri links no engine. D3 needs a desktop JS app to exist before anything can be shared with it. That is new build configuration, not a refactor.

Part of #993