Day 0:   User configures emergency access
         → contact email, countdown (7/14/30/60/90 days), vault selection
         → Server creates dormant escrow account
         → Client wraps vault keys to escrow account's X25519 public key

Day 1-N: User logs in normally
         → LastActivity timestamp refreshes on every login
         → Nothing happens

Day N+1: User stops logging in
         → Background checker runs hourly
         → Detects: time.Since(LastActivity) > CountdownDays
         → Emergency is triggered

Trigger: Server activates escrow account
         → Creates invite for the emergency contact
         → Sends invite via email (if SMTP configured) or admin delivers manually
         → Contact registers using the invite
         → Escrow envelopes grant read access to the user's designated vaults

1. Server creates escrow account with its own X25519 key pair
2. Client fetches escrow account's public key
3. For each designated vault:
   a. Client retrieves its own copy of the vault DEK
   b. Client wraps DEK to escrow's X25519 public key:
      shared_secret = X25519(user_private, escrow_public)
      wrap_key = HKDF-SHA256(shared_secret, "escrow-envelope")
      wrapped_dek = XChaCha20-Poly1305(wrap_key, vault_dek)
   c. Client uploads: EscrowEnvelope { user_id, vault_id, wrapped_key, nonce }

1. Server marks emergency as triggered
2. Server creates an invite tied to the contact's email
3. Contact registers using the invite code
4. Contact's account receives the escrow envelopes
5. Contact's client unwraps DEKs using the escrow private key
6. Contact can now decrypt the designated vaults

Registration:
  1. Client generates recovery_key (256-bit random)
  2. Client encrypts user's private keys with recovery_key
  3. Encrypted blob stored as RecoveryKeyEnvelope on the UserRecord
  4. Plaintext recovery key shown to the user ONCE (they must write it down)

Recovery:
  1. User provides recovery_key (the string they wrote down)
  2. Client decrypts RecoveryKeyEnvelope → recovers private keys
  3. User sets a new master password
  4. Client re-encrypts private keys with new password-derived encryption_key
  5. Client updates auth_verifier on the server
  6. Recovery key envelope is regenerated (new recovery key issued)