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

STATUS.md

@@ -36,11 +36,16 @@ Proven end to end on real hardware.
   the old backups stay recoverable. Both keys are now kept. **What this cannot undo:** anything
   superseded before today is gone for good, which includes both demo machines' pre-4-August keys — so
   those 51 orphaned backups were beyond reach even if the recovery codes had been kept. *(R-198)*
-- **Nothing in the recovery path has ever been performed, and that has not changed today.** Making a
-  recovery code is proven, live, with a real customer. **Using one is not.** No sealed package has ever
-  been handed back to a machine, no recovered key has ever been put back, no old backup store has ever
-  been reopened. Today's work makes the key **survive**; it does not build the path that hands it back.
-  That is what the proof exercise is for. *(R-199, R-200, R-201)*
+- *(largely fixed 4 Aug)* ~~Nothing in the recovery path has ever been performed.~~ **The key now
+  demonstrably comes back — measured on a real machine this evening.** demo-felhom fetched its own
+  sealed package from the hub with its own credential, opened it with the recovery code you saved, and
+  the backup key that came out was **identical, character for character, to the one the machine is
+  using** — and to the fingerprint the hub had recorded separately. Three independent sources agreeing.
+  A deliberately wrong code, tried five minutes earlier, was refused outright and wrote nothing.
+  **What is still NOT done, and it is the half that matters to a customer:** nothing yet *puts the
+  recovered key back*, reopens the old backup store with it, or **restores a single file**. Today
+  proves the key survives and returns; it does not prove the backups do. *(R-199 closed; R-200 half;
+  R-201 open)*
 - **One screen still tells the customer something we cannot yet promise.** The „elárvult tároló" card
   says the old backups may later be restorable with the matching recovery code. From today that is true
   for machines that re-seal from now on and **false for anything already orphaned** — and the machine
@@ -90,7 +95,9 @@ Proven end to end on real hardware.
 ## What we're working on
 
 - **Now:** the proof exercise — wipe a demo machine and recover it with a saved recovery code. It is
-  designed and waiting on your go-ahead. Both honesty fixes shipped today: a changed backup key now
+  designed, and it is now a much better bet than it was this morning: the first half of the path was
+  walked live today, so if the drill fails we will know *which* step failed instead of just "recovery
+  did not work". Waiting on your go-ahead. Both honesty fixes shipped today: a changed backup key now
   raises an alarm on the day, and the email that stated the opposite of what it measured now describes
   what it actually saw.
 - **Also tomorrow:** confirming what the 04:15 off-site run does on both machines. We expect it to
@@ -142,7 +149,11 @@ Proven end to end on real hardware.
 
 ## Changed since last update
 
-- **2026-08-04 (latest)** — **Fixed the worst of it.** The hub now keeps the off-site backup key when a
+- **2026-08-04 (evening)** — **Proved the backup key comes back.** A demo machine fetched its own
+  sealed package, opened it with the saved recovery code, and produced a key identical to the one it
+  uses. A wrong code was refused and wrote nothing. The recovery code left no trace anywhere on the
+  machine — searched, with a planted copy first to prove the search worked. *(R-199, R-200)*
+- **2026-08-04 (earlier)** — **Fixed the worst of it.** The hub now keeps the off-site backup key when a
   machine re-seals, instead of only the whole-machine one — four lines of database change that stop the
   recovery ceremony from destroying the thing it exists to protect. A changed backup key now raises an
   alarm the same day. The daily email that described the opposite of what it measured now states what it