docs: R-193 CLOSED (the recovery screen); R-213 minted for the put-back

- OPEN-ITEMS: R-193 CLOSED with both 2026-08-05 rulings (unlocking and restoring
  are separate; 'I do not want the old data' moves the store aside after a double
  confirmation), and the shape-(b) reasoning — WriteOffboxSecrets auto-generates a
  repository password on re-apply, so the literal 'fresh data area' trigger would
  have opened a window that closes by itself.
- R-213 MINTED (R-212 was and still is the highest, re-checked for the second
  writer): putting files back in place, with the live-versus-backup comparison
  named as its requirement. Not started, deliberately.
- capability map: the 'needs someone who knows to look' qualifier is GONE; what
  remains is stated narrowly — no correct-code run through the page, the put-back
  is out of scope, and the journey has not been re-walked end to end.
- 07-backup-architecture 7.0: a fifth row, and where the screen deliberately stops.
- CONTEXT: standing ruling S-34.
- STATUS: the headline change and the two things still owed as proof.

No hub change and no hub bump.

documentation/architecture/07-backup-architecture.md

@@ -367,13 +367,23 @@ here — §8 has rows where it is the actual state.
 | 3 | **The restore's default returned the wrong thing, silently** | `mode=unit` restores the recovery unit — the app's definition, configuration and database dumps — and **not the customer's files**; the userdata in the same snapshot is excluded by `--include`. The outcome message was one sentence for both modes and named neither scope. On the last step of a disaster recovery, the default quietly did not do what the person asked. | **CLOSED — controller v0.198.0** (R-204 item 3). The unit outcome names what came back, what did not, and the step that gets it; the wizard's intent card states its scope before the choice. **The size gate on `mode=full` is untouched**, and the default stays `unit`. |
 | 4 | **A rebuilt box cannot obtain an off-site credential unaided** | The one-time provider password was spent by its predecessor, so the rebuilt guest has nothing to authenticate with and an **operator Re-issue** was required. | **CLOSED — controller v0.199.0 + hub v0.96.0** (2026-08-05, operator ruling: automate it, and **the trigger is a state the BOX DECLARES**). The box now reports `offsite.state=needs_credential` when two local facts hold together — a fresh data area AND a hub-held recovery package — and the hub's `internal/offsiteheal` re-arms the stored one-time secret, minting only when there is nothing to re-arm. **Deliberately NOT automated: the escrow ceremony.** A credential is replaceable; the recovery code is not. |
 
-> **[FACT] The honest current answer, updated 2026-08-05: all four are gone, and a customer alone
-> still does not have a guided recovery — for a different reason, which is worth keeping straight.**
-> No step now REQUIRES an operator. What is missing is the OFFER: there is no customer-facing screen
-> that tells a rebuilt box's owner a sealed package is waiting, takes their recovery code and previews
-> what would come back (R-193's remaining half). The machinery is self-service; the experience is not
-> yet built. **And the whole journey has not been re-walked end to end since these fixes** — the four
-> closures are proven individually, not as one uninterrupted run.
+> **[FACT] The honest current answer, updated 2026-08-05 (controller v0.200.0): all four are gone AND
+> the customer is now offered the recovery.** A full-page screen meets the owner of a rebuilt box while
+> the hub holds a sealed package the box cannot open: it explains the situation, says plainly that
+> **nobody can replace a lost recovery code**, takes the code, opens the repository and **lists what is
+> in it** — apps, dates, sizes. No step requires an operator, and no step requires a command line.
+>
+> **WHERE THAT STOPS, and it is a real stop.** The screen **unlocks and only unlocks**. It restores
+> nothing. Putting files back is per-app, lives in the backups area, and the step after the listing —
+> a customer seeing what would change before anything is overwritten — is **not built** (→ R-213). A
+> screen that unlocks and then offers to overwrite is two decisions wearing one button, which is why
+> the operator ruled them separate.
+>
+> **What is still owed as evidence:** the final unlock has never been driven with a CORRECT code
+> through the page (no code was kept for demo-felhom's orphaned history; demo-hp's is operator-held),
+> so the live run exercised handler → agent → hub fetch → age KDF and stopped at the unseal. **And the
+> whole journey has not been re-walked end to end since these fixes** — the closures are proven
+> individually, not as one uninterrupted run. That re-walk is one more drill.
 >
 > **WHY THE TRIGGER FOR STEP 4 IS A DECLARATION, recorded here because it is the design and not an
 > implementation detail:** from the hub, an ABSENT off-site object means *never configured*,
@@ -979,3 +989,4 @@ to now *implement* D5 remains an open scheduling decision, not a blocked one.
 - It does not estimate a single RTO or RPO. Every blank in §8 is a real gap.
 - It does not answer §11. Those are the operator's.
 - It does not claim ratification.
+| 5 | **A customer had no way to BEGIN — the only route was a command line** | Everything above was self-service, and nothing told the owner of a rebuilt box that a sealed package was waiting or how to open it. | **CLOSED — controller v0.200.0** (R-193). A full-page recovery screen, shown while the hub holds a package this box cannot open; it unlocks and lists, and **restores nothing** (→ R-213 for the put-back). |