the backup promise is kept: photos deleted and returned byte-identical

The capability map's journey row now carries the half it could never finish: five
photos in, deleted the way a child would, the old route refusing and touching
nothing, the off-site restore returning them, and them opening — sha256 identical,
5 of 5, with a negative control.

Stated with it, because both are true: the bind needed ZERO operator presses (the
box registered itself and used the mail the hub sent itself), but the PBS cascade
needed ONE — the Re-issue press R-511 documents, which then succeeded because of
this morning's ep0 grant.

R-543 (P1) is the honest caveat: off-site ON by default is not off-site WORKING on
day one — a fresh box waits at „Kulcsletétre vár" until the household creates its
recovery code, and nothing asks them to, while the tier-1 row already promises that
copy. R-544 records a log line that says „escrow deleted" where the effect is
demotion to retained custody.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

documentation/audits/evidence-backup-promise-2026-09-16/phaseE-teardown.txt

@@ -20,3 +20,64 @@ VMID       Status     Lock         Name
 ##    against all 41 evidence files. Planted positive control matched 6/6, so the grep works; the
 ##    committed evidence matched 0 files. The earlier count of „22" was the WORD „password" in labels
 ##    like „Password set" — a word count, not a leak check.
+## 2026-09-16T18:16:43Z TEARDOWN, LAYER 3 — delete the HOST record, keep the customer (never RESET)
+  pre-state: {"deletable":true,"escrow_present":true,"guests":1,"log_bundles":0,"pbs_secret_present":true,"recovery_present":true,"reports":9,"status":"stale","wg_peer_bound":true}
+  delete POST at 2026-09-16T18:16:43Z
+  http=409
+  host record after: 200  (404 = gone)
+  customer record after: 200  (200 = KEPT)
+  hub log right after the delete:
+    2026/09/16 20:16:30 [INFO] Host staleness: tester-1-33b6a9 ok → stale (host_stale)
+    2026/09/16 20:16:31 [INFO] Operator email sent for tester-1/host_stale
+    2026/09/16 20:16:43 [WARN] host delete refused: tester-1-33b6a9 has key escrow (acknowledgement missing)
+## 2026-09-16T18:17:45Z delete retried WITH the escrow acknowledgement (retained custody)
+  delete POST at 2026-09-16T18:17:45Z
+  http=303
+  host record after: 404  (404 = gone)
+  customer record after: 200  (200 = KEPT)
+  hub log right after:
+    2026/09/16 20:16:31 [INFO] Operator email sent for tester-1/host_stale
+    2026/09/16 20:16:43 [WARN] host delete refused: tester-1-33b6a9 has key escrow (acknowledgement missing)
+    2026/09/16 20:17:30 [INFO] Staleness: tester-1 ok → stale (node_stale)
+    2026/09/16 20:17:31 [INFO] Operator email sent for tester-1/node_stale
+    2026/09/16 20:17:46 [INFO] host deleted: tester-1-33b6a9 (escrow deleted: true)
+    2026/09/16 20:17:46 [INFO] self-bind link emailed to the registered address of tester-1
+    2026/09/16 20:17:46 [INFO] self-bind link (hash 69b8422e…, valid 7 days) emailed to the registered address of tester-1
+    2026/09/16 20:17:46 [INFO] self-bind link auto-minted for tester-1 on host delete (the console banner's promised email now exists)
+##  THE FIRST DELETE WAS REFUSED, and it was right to refuse (18:16:43Z):
+##    „host delete refused: tester-1-33b6a9 has key escrow (acknowledgement missing)" -> HTTP 409,
+##    host record still 200, customer still 200 — nothing was dropped.
+##    This box carries a REAL key escrow because the household performed the ceremony an hour ago, and
+##    the hub will not discard a customer's sealed package on an unacknowledged delete. The documented
+##    action is to acknowledge it, which moves the escrow to RETAINED custody rather than destroying it.
+##  AND THE STALENESS ALARM FIRED TRUTHFULLY: „Host staleness: tester-1-33b6a9 ok → stale (host_stale)"
+##    at 20:16:30 CEST with an operator mail one second later — the box really was gone by then.
+##  LAYER 3 DONE (18:17:45Z), with the acknowledgement given:
+##    POST /hosts/tester-1-33b6a9/delete (confirm_host_id + delete_escrow=1) -> 303
+##    host record  -> 404 (gone)      customer record -> 200 (KEPT; RESET was never used)
+##    hub log, same second:
+##      „host deleted: tester-1-33b6a9 (escrow deleted: true)"
+##      „self-bind link emailed to the registered address of tester-1"
+##      „self-bind link (hash 69b8422e…, valid 7 days) emailed to the registered address of tester-1"
+##      „self-bind link auto-minted for tester-1 on host delete (the console banner's promised email
+##       now exists)"
+##    So R-509's automatic e-mail fired again, on a second box, at the second of the delete.
+##  A WORDING MISMATCH WORTH CHECKING RATHER THAN REPEATING: the refusal text says the acknowledgement
+##    moves the escrow „to retained custody", while the log line says „escrow deleted: true". Those are
+##    two different statements about a household's last key, so the customer record is read below
+##    instead of trusting either sentence.
+##  THE AUTOMATIC CONNECT E-MAIL — PROVEN AGAIN, on a second box in the same session:
+##    host delete at 2026-09-16T18:17:45Z  ->  mail in the customer's inbox at 18:17:46Z (ONE second),
+##    „[Felhom] Kösd össze a Felhom dobozodat", to tester1@felhom.eu, body „Elkészült a Felhom dobozod,
+##    és készen áll az összekötésre… https://hub.felhom.eu/bind/…", link valid 7 days.
+##    Requirement was two minutes. R-509 now has two independent live proofs today (12:23:00Z and
+##    18:17:46Z), on two different boxes.
+##  THE ESCROW'S FATE, answered from the hub's own text rather than from either log line:
+##    „host deletion only demotes custody, never destroys it"
+##    „1. The host(s) will be deleted — recovery-key custody is demoted to RETAINED custody, not
+##     destroyed." …and the customer delete is named as „the one true purge point".
+##    So the acknowledgement demoted the custody; it did not destroy the household's sealed package.
+##    The log line „escrow deleted: true" is the FLAG's name, not the effect — recorded as a row.
+##  CUSTOMER RECORD AFTER EVERYTHING: present (200), with e-mail, domain, tunnel and DR tier intact,
+##    and „waiting — no host enrolled yet — the Day-0 install enrolls…" — exactly the state a customer
+##    is in between boxes. RESET was never used.