Part 0: correct the PETI record - the mitigation it named does not exist

The row said a drive failure there means offsite-only recovery. Re-read from the
hub's own store: no host row (deleted 2026-07-15 08:56:22, escrow_acked=0), no
escrow of any kind, and offsite backup never ran once (escrow_state pending,
snapshot_count 0 - the fork-4 guard working, not a fault). The local app-data
repo was empty too and the whole-guest vzdump shares the failing device. If that
drive fails today, everything on it is lost.

Records the fact and leaves the parked/not-parked ruling open - that is the
operator's call and does not need restating to be true.

STATUS.md no longer reads the absence of a hub record as reassuring.

STATUS.md

@@ -58,8 +58,11 @@ So I took your stated fallback: the old store was **moved aside, not deleted** (
 **One read of the hub's own records, no machine touched.** The hub holds backup keys for exactly
 **three** machines. Both demo boxes lost their old key in the same four-hour window on 4 August,
 before the retention fix was in force — that is the whole population of the problem, and it is
-entirely ours. **The tester's machine has no record at all**, so it cannot be affected; and anything
-enrolled from now on is covered, because the fix has been in force since 4 August.
+entirely ours. **The tester's machine has no record at all** — so it cannot be affected by *this*
+defect, and that is the only reassuring thing about it: the reason it has no record is that its host
+row was deleted on 15 July, and it has **no off-site copy, no key and no local backup either**. See
+the `PETI` row in the register. Anything enrolled from now on is covered, because the fix has been in
+force since 4 August.
 
 I ran a control before trusting the query: it had to say *material present* for a machine known to
 have it and *absent* for one known not to. It did both.