Add a source-access wrapper for the caller's own encryption key

vault-recovery-custody (consult round 1): the member's vault encryption private key is held only as encrypted wrappers — one per PRF-capable passkey (webauthn_prf, KEK derived from that credential's WebAuthn PRF output) plus at most one recovery_code wrapper (KEK derived from the source recovery code, a decrypt-only secret that never authenticates). Every wrapper is born PENDING and counts for nothing until the possession-proof activation (POST …/wrappers/{wrapper_id}/activate) — the response carries the ECDH challenge. The swrap2 blob is sealed client-side with a canonical context binding (principal, key id, wrapper id, kind, credential, FULL public-key hash, RP id) as both HKDF info and AAD; the server cannot open or validate the ciphertext. For webauthn_prf, the credential is SERVER-derived: pass elevation_id from a gitvault.wrapper.add step-up verify — the client is never authoritative for the credential id. Adding a device is adding a wrapper — the published key and ek_ fingerprint never change. For a NEW (random-key) enrollment, use the atomic form: pass wrappers[] on POST /agent/v1/whoami/encryption-key so the key row and its first wrapper commit in one transaction (both pending until activation).