docs(future): mark security items #1-#3 built (deploy-gated) with commit refs

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Future.md

@@ -23,14 +23,23 @@ Non-blocking ideas: things that work today but could be better, plus feature ide
   defeats the on-screen identity check does NOT defeat this). Needs mail infra (SendGrid / a Firebase Auth action)
   — deferred for that reason. R24-b shipped the on-screen identity + confirm + owner self-alert as the pragmatic
   interim.
-- **Restore-request lifecycle cleanup.** A `restore_requests` doc left at `READY` (partner wrapped the key but the
-  recipient never completed) leaves an ECIES `keybox` — ciphertext sealed only to the recipient, useless to
-  anyone else, but untidy. Add a **scheduled cleanup** of expired requests (and their keyboxes). R24-b already
-  enforces expiry at fulfil time and deletes any stale request before a re-request.
-- **Owner-alert precision.** The R24-b "was this you?" self-alert also reaches the *requesting* device (harmless).
-  Optionally exclude it via a client-written token hint on the request (would add a rules-allowed field).
-- **Couple-key rotation / forward secrecy.** A couple-key compromise exposes all history incl. backups (no FS
-  today). Add rotation (both devices re-key) — hard but the right long-term hardening.
+- **Restore-request lifecycle cleanup — BUILT 2026-07-15 (commit `8496bbed`), deploy-gated.** Hourly
+  `cleanupExpiredRestoreRequests` (collectionGroup on `expiresAt`, catches orphans under deleted couples;
+  delete-first then a quiet expiry nudge to the requester through the house pipeline). Awaiting:
+  `firebase deploy --only firestore:indexes` + `--only functions:cleanupExpiredRestoreRequests`, then live verify.
+- **Owner-alert precision — BUILT 2026-07-15 (commit `2dd09d5d`), deploy-gated.** Requesting device embeds its
+  FCM token (create-only optional field, best-effort); both self-alerts skip that one device, partner push
+  untouched. Awaiting: `firebase deploy --only firestore:rules` +
+  `--only functions:onRestoreRequested,functions:onRestoreFulfilled`, then live verify.
+- **Couple-key rotation / forward secrecy — PHASE 1 BUILT 2026-07-15 (commit `2c44cc6f`), deploy-gated; PHASE 2
+  PLANNED (own checkpoint).** Phase 1 = rotate-forward: new Tink key primary + old retained (history readable,
+  zero wire/`isCiphertext` changes), same-phrase re-wrap + strictly-increasing `keyGeneration` on the couple doc,
+  partner adopts automatically on Home load, 🔑 alert via `onCoupleKeyRotated`, Settings → Security row.
+  Fail-closed path VERIFIED LIVE pre-deploy (PERMISSION_DENIED → "nothing changed", app healthy). Protects
+  FUTURE content only. Awaiting: rules + `--only functions:onCoupleKeyRotated` deploys, then 2-device happy-path
+  verify (throwaway couple first). Phase 2 (forward secrecy for history) = per-family idempotent re-encrypt
+  sweeps + backup re-snapshot under the new key + both-devices K1-destruction handshake — plan in
+  `/home/kaspa/.claude/plans/i-want-you-to-recursive-clover.md`, NOT started (pre-execution review checkpoint).
 - **Server-independent anti-rollback freshness.** A malicious server could serve a stale manifest to hide recent
   messages; today mitigated by the `generation` counter + a Phase-1 Firestore cross-check. Add a signed/monotonic
   freshness signal for the Option-B world.