demo-felhom is protected again, and the authorised recovery could never have worked

Checked before acting, and the check is the finding. The box's local key and the
hub's sealed escrow key hash to the SAME value (c60c8bc737a6b7c6...), and that
key answers "wrong password or no key found" against its own repository. Running
the recovery would have returned a key the box already held and which was already
proven not to open the store.

The store was written under 48741892f0ef4d59... -- host_escrow_superseded id=4,
superseded 2026-08-04 07:20:08, identity_blob NULL. The restic password lives
only in the identity bundle (escrow/identity.go:39, read by recover.go:91), so it
is unrecoverable by construction; the surviving K-escrow payload is 64 bytes, a
wrapped key, far too small to carry it. Same shape the register already records
for demo-hp, four hours the wrong side of the retention fix.

Took the operator's stated fallback instead: the orphan reset through the
customer's own card. Old store moved aside, never deleted, to
/home/felhom-repo.orphaned-20260810 (1.2 GB); fresh repository under the current
key; offbox_repo_reset audited hub-side. Then PROVEN rather than assumed --
last_status ok, 10s, and the snapshot's CONTENTS listed: opengist compose files,
manifest.json and volume-dumps/opengist_opengist_data.tar. Not an empty backup
calling itself successful.

R-202 gains hard evidence: the orphan card promises those set-aside backups may
be restorable later with their recovery code. For these 1.2 GB that is false and
unfixable, and it is said to the customers most likely to read it.

STATUS.md

@@ -21,11 +21,11 @@ untouched and still blocked, as intended.
 first scheduled run since the rebuild is tonight at 04:15. Two apps it had before the rehearsal
 (opengist, privatebin) were never reinstalled; only Calibre-Web was, as the walk needed.
 
-**demo-felhom has had no off-site backup for a week, and it will not fix itself.** Its repository is
-flagged **orphaned**; the last attempt was 2026-08-05 and **no run has ever succeeded**. The hub
-raised `offsite_stale` this morning and mailed you — that alarm is **true**. The remedy is the
-recovery ceremony on that machine's own screen, using its recovery code, which is the one thing I
-should not do without you saying so. *(R-278.)*
+**demo-felhom is protected again — and the recovery you authorised turned out to be impossible.** Before running it I checked, and the sealed package holds *the same key the machine already had* — a key that provably does not open its own backup store. Recovering it would have handed back something useless. The store was written under an older key whose sealed copy was **not retained** (the retention fix landed hours too late for it), so **those 1.2 GB are permanently unreadable by anyone, including us**.
+
+So I took your stated fallback: the old store was **moved aside, not deleted** (`/home/felhom-repo.orphaned-20260810`), a fresh one was created under the current key, and a real backup ran — **succeeded in 10 seconds**, and I listed what is inside it rather than trusting the green tick: OpenGist's configuration, its manifest and its data volume. **The week without off-site protection is over.** *(R-278 closed.)*
+
+**One thing that needs your judgement, not mine.** The card that offered this told the customer their set-aside backups *may be restorable later with their recovery code*. For these ones that is simply untrue, and it is said to precisely the people who have just lost their history. *(R-202 — now evidenced.)*
 
 ## What works