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.

STATUS.md

@@ -22,16 +22,19 @@ over; and the file was restored **byte for byte identical**. *(R-201)*
 
 ## What's broken
 
-- **All four recovery steps are now automatic — but a customer still would not know to start.** The
-  four steps that stood between "the key is recoverable" and "the file is back" are closed *(R-204)*:
-  the reset-code tool works first time; re-issuing the storage credential no longer falsely marks the
-  recovery key "stale"; the everyday restore says in plain Hungarian that it returned the app's
-  settings and database and **not** your documents; and, as of today, **a rebuilt machine asks for its
-  storage credential itself and the hub answers** — no Re-issue click. **What is missing is the
-  offer:** there is no screen that meets the owner of a rebuilt machine, tells them a sealed package
-  is waiting, takes their recovery code and shows what would come back. So nothing needs *you* any
-  more, but it still needs someone who knows to look. **And the whole journey has not been re-run end
-  to end since these fixes** — the four are proved one at a time, not as a single walk. *(R-193)*
+- **A customer can now get their backups open on their own — but not yet put the files back.** Every
+  step from a rebuilt machine to an open backup store is done, and today the last piece landed: a
+  **full screen** meets the owner of a rebuilt machine, explains that the backups are still there,
+  says plainly that **nobody can replace a lost recovery code**, takes the code, and shows what is in
+  the store — which apps, from when, how big. Nothing needs you, and nothing needs a command line.
+  **What it deliberately does not do is put files back.** That is per-app, in the backups area, and
+  the piece that would guide it — showing what would change before anything is overwritten — is not
+  built yet. *(R-193 closed; the put-back is R-213)*
+- **Two things still owed as proof.** The final unlock has never been done with a **correct** code
+  through the new screen: no recovery code was kept for the N100 machine's orphaned history, and the
+  HP machine's is in your hands, not ours — so the live test ran the whole chain and stopped at the
+  last step. **And the whole journey has not been re-run end to end since these fixes** — the pieces
+  are proved one at a time, not as a single walk. That re-run is one more drill. *(R-201)*
 - **Rebuilding a machine still throws away its off-site backup HISTORY.** The machine invents the key
   that encrypts its own off-site backups, and a rebuilt machine invents a brand-new one. Both demo
   machines did this on 3–4 August — 51 backups (~1.2 GB) between them. The old key now survives the
@@ -47,6 +50,14 @@ over; and the file was restored **byte for byte identical**. *(R-201)*
 
 ## What shipped recently
 
+- **2026-08-05** — **The recovery screen: a customer whose machine was rebuilt is now told, and shown
+  how.** Until today they had everything needed to get their data back and no way to find out — the
+  only route was a command line. The screen unlocks the backups and lists what is in them; it does
+  **not** restore anything, because unlocking and restoring are two different decisions and mixing
+  them would turn one clear moment into a wizard. Three ways out, none of them a dismiss button — and
+  the „most nem" option keeps the route to the data permanently visible in the backups area, because
+  a notice someone clicks past once is a notice that never happened. *(R-193)*
+
 - **2026-08-05** — **The orphaned backups are deleted — and the list you were given was wrong, which
   is why you were asked again.** You had approved "about 1.2 GB in two set-aside stores". Measured
   before touching anything: there were **three** set-aside stores totalling **~1.45 GB** — and the