teardown of two venues; R-218/R-220 CLOSED, R-236 WITHDRAWN, R-238 reclassified

Part 0 — c11 and rewalk destroyed, three layers each plus the off-site side and
the WireGuard peer, via the hub's own cascade (external teardown FIRST, DB purge
LAST). 37.3 GB reclaimed on c11-scratch, matching the 20G+17G measured. Positive
control after each: part4 must still be found, and was. ep0 namespaces now exactly
demo-felhom, demo-hp, part4.

The cascade refuses to delete a live host and there is no decommission endpoint,
so both boxes were stopped and aged past the hub's 30m stale_threshold first.

Register corrections — the durable record was wrong about two shipped fixes:
  R-218 REOPENED -> CLOSED. Shipped controller v0.203.0, proven live on a
        genuinely rebuilt box: the hub re-staged at 13:24:57Z and the box
        collected it on a tick, no guest command line, no operator action.
  R-220 "OPEN — NOT FIXED" -> CLOSED. Shipped agent v0.127.0, proven live after a
        real guest purge with both raw mounts still on the surviving host:
        /disks/candidates returned both drives (before: two empty lists) and both
        re-attached through the customer endpoint.

R-236 WITHDRAWN — I FILED THIS WRONGLY. The hub log shows offsiteheal re-staged
the stored secret at 13:24:57Z after its documented two-report debounce, with no
provider credential minted. My Re-issue at 13:26:39Z came 102s LATER, was
redundant, and minted an unnecessary provider credential (subaccount 284735) —
the very double-issue the offsite-delivery guard warns about once a minute in the
log. "Nincs teendod" is true; I did not wait ~16 minutes. Operational lesson, not
a product defect.

R-238 reclassified as a harness artifact (mode=full without confirm=1 is step 1 of
a deliberate two-step and starts no job by design); its real residue — the total
silence of that step — is fixed in controller v0.204.0.

R-237 CLOSED by controller v0.204.0.

documentation/tests/teardown-2026-08-06.md

@@ -0,0 +1,72 @@
+# Teardown ledger — the campaign venues (2026-08-06)
+
+Three throwaway appliances had accumulated, each with its own storage sub-account, hub record, tunnel
+peer and off-site repository. **Two were destroyed here.** The third (`part4`, VM 323) was kept until
+Parts 1 and 3 had banked their findings, and goes separately.
+
+## What was matched, and how
+
+Matched on **identity** — customer id → host id → off-site sub-account → wg peer — never on size. The
+hub's own delete-preview (`GET /configs/<id>/delete`) was used as an independent enumeration and
+agreed with the hand-built one in every field.
+
+## The cascade is the hub's, not a hand-deletion
+
+`POST /configs/<id>/delete` runs the designed teardown: leg 1 hosts (including
+`DELETE FROM wg_peers WHERE host_id = ?`), leg 2 the committed reset with **external teardown FIRST**
+(off-site store + PBS namespace destroyed), leg 3 residue, leg 4 the customer record and **all** escrow
+ciphertext. Its own confirmation: „offsite tároló és PBS névtér megsemmisítve… Visszafordíthatatlan."
+
+**Six gates, all of which had to be satisfied deliberately** — three acknowledgements
+(`ack_hosts`/`ack_reset`/`ack_purge`), a type-to-confirm `confirm_id`, an `expect_hosts` race guard,
+and — the one that shaped the whole operation — **the cascade refuses to delete a live host**:
+
+> Delete refused: host c11-36d660 is ONLINE. Decommission the box first — the cascade never deletes a
+> live host.
+
+There is no hub decommission endpoint; the word appears only in that refusal. So both VMs were
+**stopped** and the hub was allowed to age them past its `stale_threshold` (**30m**, from the deployed
+`hub-config`) before the cascade would accept them. `rewalk` aged out at ~21 min of silence, `c11` at
+~28 min — the two boxes' last reports had landed at different points in their cycles.
+
+## Venue 1 — `c11` "Campaign 11"
+
+| Layer | Item | After |
+|---|---|---|
+| Machine | `demo-hp` VM **321** `c11-appliance` (200 G + 50 G + 50 G + efidisk, **20 G on disk**) | `qm destroy 321 --purge` — absent from `qm list` |
+| Hub host | `c11-36d660` | 0 occurrences |
+| Hub customer | `c11` (residue 340 rows, 1 superseded blob) | 0 occurrences |
+| Off-site | Storage Box sub-account **`u629488-sub4`** | 0 occurrences |
+| Off-site | `ep0` PBS namespace **`c11`** | gone |
+| Network | WireGuard peer **10.77.0.5** | 0 occurrences |
+
+## Venue 2 — `rewalk` "Re-walk R-201"
+
+| Layer | Item | After |
+|---|---|---|
+| Machine | `demo-hp` VM **322** `rewalk-appliance` (**17 G on disk**) | `qm destroy 322 --purge` — absent |
+| Hub host | `rewalk-1ab77d` | 0 occurrences |
+| Hub customer | `rewalk` (residue 93 rows) | 0 occurrences |
+| Off-site | Storage Box sub-account **`u629488-sub5`** | 0 occurrences |
+| Off-site | `ep0` PBS namespace **`rewalk`** | gone |
+| Network | WireGuard peer **10.77.0.6** | 0 occurrences |
+
+## Space returned, measured
+
+`c11-scratch` used: **58,578,256 KiB → 21,228,640 KiB** = **37.3 GB reclaimed**, against 20 G + 17 G
+measured before deletion. Free went 874.8 GB → 912.1 GB.
+
+## The positive control
+
+An absence proves nothing unless the instrument can still find something. After each cascade the same
+greps were run for **`part4`**, which must survive: host `part4-905bdb` still present (2 rows), wg peer
+**10.77.0.7** still present, `ep0` namespace `part4` still present. So the zero counts above are
+measurements, not a broken query.
+
+`ep0` namespaces after both teardowns: `demo-felhom`, `demo-hp`, `part4` — exactly the three that
+should remain. Nothing on `ep0` outside the campaign's own namespaces was touched.
+
+## Untouched, as scoped
+
+`demo-hp` itself and its guest 9201, `demo-felhom`, `drill-r50` (VM 300), DooPlex, the tester's box,
+and every `ep0` namespace that is not the campaign's own.