CAMPAIGN-11: hygiene, what-did-not-run, venue end state, and the session report

The recovery codes are shredded with the plant->find->shred->fail-to-find
control the brief asks for, and THE CONTROL PAID FOR ITSELF ON ITS FIRST RUN:
it found the Phase 0 code in ~/.config/credentials as R_CAMPAIGN_11 — a copy
this session did not create and would never have looked for. Without it, a
'codes shredded' claim would have been false. That key was removed from the
shared file with a verified diff (every other line identical, nine keys intact)
and HUB_PW re-tested at hub:200.

Consequence stated plainly rather than left to be discovered:
/home/felhom-repo.orphaned-20260805 (12 535 KB, the three Phase 0 sentinels) is
now permanently unopenable — which is what the set-aside screen promises, and
teardown removes it anyway.

Venue left WORKING and said so: ONLINE, 4 containers healthy, backup target not
degraded, off-site on 2 snapshots. Two things a future session needs: the raw
/mnt/{adatok,mentes} mounts are deliberately left unmounted (R-220's
workaround), and the appliance root credential was shredded — re-fetch it from
the hub.

REPORT-campaign11-phase24.md rather than REPORT.md, per the repo's
parallel-session rule.

No product code changed. No version bumped.

documentation/tests/campaign11-evidence-2026-08-05/journal-phase24.md

@@ -833,3 +833,85 @@ self-heal, which is R-218's negative control.
 was true it is said so: the restore-test's silence was predicted in advance, and the whole-guest
 tier's silence is left explicitly unresolved rather than counted as a pass.
 
+
+---
+
+# Hygiene — the recovery codes, shredded with a positive control
+
+The brief's warning was earned: *"a sweep pointed at a path that did not exist inside the guest and
+its zero hits meant nothing. Prove the sweep works before trusting it."* So the sweep was proved
+first, and **it immediately found a copy this session did not know about.**
+
+**The sweep searches by CONTENT, never by filename**, and the pattern is passed to `grep -f` from a
+file so the code never appears on a command line or in a process argument.
+
+### 1. Plant → 2. Find (the positive control)
+
+A copy of each code was planted at a known extra path. The sweep over DooPlex (`~/.config`,
+`/tmp/claude-1000`, `/tmp`) and demo-hp (`/root`, `/tmp`) returned:
+
+```
+phase0:  ~/.config/credentials                       ← ⚠ NOT KNOWN TO THIS SESSION
+         ~/.config/campaign11/R_C11_phase0.txt
+         <scratchpad>/PLANTED_phase0.txt             ← the planted control, found ✅
+         <scratchpad>/R_C11_phase0.strip
+         demo-hp:/root/R_C11_phase0.strip
+phase3:  ~/.config/campaign11/R_C11_phase3.txt · PLANTED_phase3.txt · .strip · demo-hp:/root/…
+```
+
+> **The control paid for itself on its first run.** `~/.config/credentials` — the *shared* credential
+> store — held the Phase 0 recovery code as **`R_CAMPAIGN_11`** (line 10). Nothing in this session put
+> it there. Without the planted-copy control there would have been no reason to sweep at all, and a
+> "codes shredded" claim would have been **false**.
+>
+> That file is the same one whose values are echoed by a failed `source` (§harness trap 1). A recovery
+> code living there is the two hazards composed.
+
+### 3. Shred
+
+**DooPlex** — all six files in `~/.config/campaign11/` (`R_C11_phase0`, `R_C11_phase3`,
+`dashboard_pw`, `managed_root_pw`, `retrieval_passphrase`, `root_pw`), then the directory itself;
+the scratchpad's `.strip` files, `appliance_pw.txt`, `dashpw.txt`, `reveal.json`. All with `shred -u`.
+
+**`~/.config/credentials`** — `R_CAMPAIGN_11` removed. Done carefully because that file also holds
+`HUB_PW`, on which this session depended: a backup was taken, the key removed by exact match, and
+then **verified** — `diff` of every other line reports **identical**, the nine remaining keys are
+unchanged (`HETZNER_API PASSWORD TS_KEY HUB_PW ISO_S3_* R_DEMO-FELHOM R_DEMO-HP`), and `HUB_PW` still
+authenticates (`hub:200`). The backup was shredded afterwards.
+
+**demo-hp** — the four `.strip` files, `.c11pw`, `.c11dashpw`, `.c11sess`, `f8_out.txt` shredded; the
+helper scripts removed.
+
+### 4. Fail to find
+
+Re-swept with the planted copies as the pattern — **the only remaining matches were the planted files
+themselves**, on both hosts. demo-hp returned nothing at all. The planted copies were then shredded
+and their absence verified by path, along with `~/.config/campaign11/`.
+
+**The captured HTML pages are covered by that sweep**, not merely assumed clean: step 4 searched
+`/tmp/claude-1000` recursively, which contains every `*.html` capture taken this session, and none
+matched.
+
+**Not swept, and why:** the guest was not searched for the two real codes, because putting the pattern
+there to search for it would be the leak. **F1 already covers the mechanism** — a sweep of the guest's
+data dir, `/var/log`, `/tmp` and `docker logs` for the *wrong* code returned zero product hits with a
+planted canary passing first, and the same code-handling path served every unlock.
+
+### ⚠ One consequence, stated plainly
+
+**Shredding the Phase 0 code makes `/home/felhom-repo.orphaned-20260805` permanently unopenable.**
+That is 12 535 KB holding the three Phase 0 sentinels. It is exactly what the set-aside screen tells a
+customer will happen, teardown will remove the repository anyway, and R-222 means no read path exists
+for it regardless — but it is a door that is now closed for good, and it should be closed knowingly
+rather than discovered later.
+
+### Other hygiene
+
+- **No secret is in any committed file.** Every hash quoted is a sha256 prefix.
+- **`git add -A` never used**; `git status --porcelain` checked before each commit; no foreign file
+  was swept (a parallel session shares this clone).
+- **The pre-push hook is armed** (`core.hooksPath=.githooks`) and ran green before every push;
+  **no `--no-verify`**.
+- **CI confirmed green by run ID** for all pushes: runs **179–184**, each matched to its `head_sha`.
+- **No product code changed. No version bumped.**
+