R-201 re-walk: the data PASSES again, the journey still FAILS — two dead ends, down from four

Asked Campaign 11 Phase 1's question a second time, on the fixed build, on a
NEW appliance (VM 322, customer rewalk). The Campaign 11 venue was untouched.

THE DATA: PASS. All three sentinels byte-identical out of the pre-destruction
snapshot a7bc23bd in 23s through the customer's own restore flow — including a
12 MB binary and an accented Hungarian filename whose NAME BYTES are identical
too (verified as hex, not as rendered text).

THE JOURNEY: FAIL, two dead ends against Phase 1's four.
 1. R-218's CONSUME half. The hub re-staged the credential at 11:44:57 saying
    'the box re-consumes on its next cycle'; a full cycle ran at 11:55:46/54
    (with a positive control that it ran) and it did not. A census of the
    customer-reachable actions found none that fetches it. Only a command line
    INSIDE THE GUEST moved it — 18s, confirming nothing was wrong with the
    credential, target or key: only the trigger. R-218's row said SHIPPED and
    over-claimed; it is corrected to REOPENED for the consume half.
 2. R-220. Drives still unenrollable after a rebuild, needing a Proxmox-host
    unmount; without it no app redeploys and the restore page stays empty.

Unaided RTO STILL UNDEFINED. Attended: +45s key placed, +24m12s tier up,
+30m13s data verified. The 30m must not be quoted as the customer number.

What passed and is new: the recovery screen appeared WITHOUT being sought,
answered all three questions with a seal date matching the hub exactly, the
emailed reset code worked first try, the unlock was a real 1.528s unseal, and
R-225's fix was seen working in the wild (unknown, not a false zero).

R-216 part 4 reproduced live: the reinstall downgraded the hand-installed agent
0.126.0 -> 0.125.0.

DELIVERY GAP recorded as owed and NOT conflated with the journey: a fresh
install landed on controller 0.201.0 / agent 0.125.0 — the vouched versions,
neither carrying the fixes — installed by hand. Nothing was vouched.

Capability map row STAYS FAIL. Campaign 11 doc gets a dated ADDENDUM, not a
rewrite.

documentation/audits/CAMPAIGN-11-recovery-journey-2026-08-05.md

@@ -35,6 +35,22 @@ Evidence: `../tests/campaign11-evidence-2026-08-05/` — `journal.md` (Phases 0,
 > which stays **FAIL** until a re-walk passes. **R-214, R-220, R-221 remain open**, and R-220 is still
 > worked around by hand on this venue.
 
+> **ADDENDUM 2026-08-06 — THE RE-WALK (R-201). The body below is NOT rewritten.**
+>
+> Phase 1's question was asked again on the fixed build, on a **new** appliance (VM 322, customer
+> `rewalk`) — this campaign's venue was left untouched. **The data half PASSED again**: all three
+> sentinels byte-identical, including an accented Hungarian filename whose **name bytes** are also
+> identical, restored in **23 s**. **The journey half still FAILS, with TWO dead ends instead of
+> four**: R-218's *consume* half (the hub re-stages, the box never collects — only a guest command
+> line moves it) and R-220 (drives unenrollable after a rebuild). **The unaided RTO remains
+> undefined.**
+>
+> Two of this campaign's findings were reproduced live: **R-216 part 4** (the reinstall downgraded the
+> hand-installed agent back to the vouched version) and **R-220**. One of last night's fixes was seen
+> working in the wild: **R-225** (an unread store said "unknown", not a false zero).
+>
+> Evidence: `../tests/rewalk-r201-2026-08-06/journal.md`.
+
 ## 1. Venue and baselines
 
 | | |