web: give each device a signing identity key

[FSM1]

Give each device an identity key that actually signs — ADR 0009 D4.

v1 minted a per-device Ed25519 keypair, stored it in IndexedDB wrapped under HKDF-SHA256(vaultPrivateKey, info="cipherbox-device-key-wrap-v1") → AES-GCM, derived deviceId = hex(SHA-256(publicKey)) — and then never signed anything with it. No caller reads its private half anywhere in the tree. It was inert identity material, which is why the approval exchange ended up bound to self-reported strings.

Work

• Mint, store and load a device identity key, and use it: sign the approval request over the ephemeral public key being offered, and sign the response.
• Register the device public key with the account so the API can verify those signatures.
• Decide what happens when the store is cleared — a device that loses its key is a new device, and that must be a defined path rather than a stuck one.

Design note

v1's wrapping key derived from the vault private key, which means the device key is unavailable exactly when it is most needed: before reconstruction, on a device that cannot yet reconstruct. That is why v1's approval request fell back to an ephemeral throwaway deviceId. Whatever v2 chooses, the device identity must be usable before the vault key exists, or it cannot sign the request it is meant to bind.

Acceptance

• A request and a response each carry a signature the API verifies against a registered device key.
• The device key is usable before vault reconstruction.
• A cleared store yields a defined new-device path, not a wedge.

Part of #1262

[FSM1]

Two constraints worth settling before this is picked up, both consequences of the key needing to work before reconstruction.

The rule-4 carve-out now covers this. #1270 amends AGENTS.md so browser-held key custody via WebCrypto is explicitly permitted for a key that must be non-extractable or must exist before the engine has a session. This key is named in it. So the device key is expected to live in WebCrypto rather than in crates/core, and that is the sanctioned shape rather than a workaround.

The curve choice is forced by non-extractability, not by preference. v1 used Ed25519 through a JS library, which means the private half existed as raw bytes in JS — extractable by definition, and in fact returned as a Uint8Array that was never zeroized. If v2 wants a key WebCrypto will hold non-extractably and sign with, ECDSA P-256 is the safe choice: crypto.subtle support for Ed25519 is uneven across the engines this ships to, whereas P-256 signing with extractable: false is universally available.

That is a deliberate divergence from v1 and from the Ed25519/secp256k1 signing line in AGENTS.md rule 5 — which is about protocol signing in the KDF catalog, not about a local device credential. Worth stating in the implementation so it does not read as drift.

The consequence for #1264: the API verifies these signatures, so the algorithm is part of that contract too.