docs: the offsite key is proven recoverable (R-199 closed, R-200 half, R-201 scoped)

documentation/architecture/03-host-agent.md

@@ -409,6 +409,24 @@ retained row carries both.
   predates the `ResticRepoPassword` field. Tracked as R-199/R-200/R-201; evidence
   `documentation/audits/RECON-offsite-dr-chain-2026-08-04.md`.
 
+#### Serving a blob back to its own box (hub v0.94.0 + agent v0.125.0, R-199)
+
+Retention without retrieval is custody, not recovery. Since 2026-08-04 a host reads its own sealed
+identity blob from `GET /api/v1/hosts/{host_id}/escrow` — self-scoped by the per-host key, the mirror
+of the PUT that stored it — and opens it locally with the customer's recovery code via the agent's
+`POST /escrow/recover-offsite-password`, which returns **only** the offsite repository password.
+
+**This is a deliberate widening of who can obtain the ciphertext**, recorded in `CONTEXT.md` S-29 and
+in the handler itself: it previously took an operator arming recovery mode, and now takes only that
+box's own credential. The blob remains unopenable without R, and every retrieval raises an
+operator-visible `escrow_blob_served` event. The operator-driven re-enroll/restore-directive path is
+unchanged and keeps its recovery-mode gate.
+
+**Proven end to end on demo-felhom, 2026-08-04:** the recovered repository password's sha256 was
+byte-identical to the one on the box, and to the hash the hub had independently recorded. **The chain
+stops there** — nothing installs a recovered password, reopens a repository with it, or restores a
+file.
+
 **The honesty property above is unchanged and now has a second edge:** losing `R` and the box makes
 the offsite backups unrecoverable by anyone — *and* an older generation's data is recoverable only
 with **that generation's** recovery code, which the customer must still hold. A current recovery code