R-193: demo-hp offsite restored on the box; escrow correction recorded

Re-issue through the designed endpoint: fresh password staged 07:11:51, settle-gate
GO, consumed 15s later at 07:12:06, offsite configured at 07:12:09 against the SAME
sub-account (275124) and repo path. Both boxes now escrowed.

CORRECTION to this session's own reading: the escrow did NOT recover by itself.
escrow_state went pending -> escrowed 15s after the apply and I inferred automation;
the operator had run the ceremony. It needed a human on both boxes — demo-hp at
07:16:02, demo-felhom at 07:20:28 (its escrow had been pending since its own rebuild
the day before). A 15-second state change is not evidence of automation, which is the
same class as reading an absent log line as success.

Snapshot continuity is NOT established: both boxes report snapshot_count 0, but the
run-history keys are ABSENT rather than zeroed — a controller that has never run an
offbox backup, not an empty repo. The 04:15 run decides it.

STATUS.md

@@ -20,13 +20,13 @@ Proven end to end on real hardware.
 
 ## What's broken
 
-- **One demo machine has no off-site copy of its app data, and rebuilding it is what took it away.**
-  `demo-hp` was rebuilt on 3 August; before that its off-site backup was healthy and had run
-  successfully at 04:16 that morning (15 snapshots). The rebuilt machine came up without it and has
-  not had it in 108 check-ins since. **The cause is that the off-site password is delivered exactly
-  once and a rebuilt machine cannot ask for another** — the other demo machine survived the same
-  rebuild only because it happened to have an unused password waiting for it, and recovered in 76
-  seconds. Nothing about that difference was designed. *(R-193)*
+- **Rebuilding a machine silently takes away its off-site app-data backup.** `demo-hp` was rebuilt on
+  3 August and came up without one, and stayed that way for a day. **Fixed on 4 August** — re-issued,
+  the machine picked the new password up in 15 seconds and reattached to the same repository, and you
+  escrowed the key. **The underlying fault is not fixed:** the off-site password is delivered exactly
+  once and a rebuilt machine cannot ask for another, so this will happen again on the next rebuild.
+  The other machine survived the same rebuild only because an unused password happened to be waiting
+  for it. *(R-193)*
 - **The daily email about it tells you the wrong story**, and the automatic repair that exists for
   this declines without saying why. The message says the password was never applied; it was, on
   23 July, and worked for eleven days. *(R-192)*