R-178 CLOSED: both demo boxes reinstalled from the merged golden and proven

Two boxes, two DIFFERENT supply paths, so the session proved the disk shape and
the delivery route rather than one of them twice.

demo-hp (layout proof, --golden <local volid>): mp0 at /var/lib/felhom,
backup=1, 70G, no mp1; /var/lib/docker and /mnt/sys_drive both real mounts of
its subdirectories via fstab; one df figure and one device id (64519) on all
three paths; reboots 3/3 with the binds surviving each.

demo-felhom (pipeline proof, --force-gitea-golden): fetch_verify succeeding
against the vouched manifest for BOTH artifacts -- 'verified sha256
54e2a4c431daf580... matches the hub manifest' for the golden, a7763d31... for
the agent. 250G single volume, grep -c '^mp1:' = 0, reboots 3/3.

Journey proven on both, endpoint-level: claim -> deploy -> back up -> restore,
with a planted marker returning byte-identical on each box. Ceiling measured
gone: 65 GiB and 233 GiB available to a recovery unit, against 19 and 45.

R-165 -> IMPLEMENTED, not PROVEN-LIVE, on the operator's ruling. B2, which that
row records as the bulkhead's replacement, fired live for the first time and
does refuse per app, delete nothing and alert -- but it is checked only in
captureAllRecoveryUnits while runVolumeDumps writes the bulk unguarded, and its
'the previous unit is untouched' claim was measured false (182,272 B dump
replaced by 2,147,666,432 B under a manifest still dated 06:34:26). -> R-181.

New: R-179 (uninstall leaves NAS network-storage units), R-180 (--archive-storage
not cross-checked against the ACL grant; 403 at step 8/8 after root@pam is
rotated), R-181. Third instance of R-115 recorded (agent 0.120.0 unpublished).

No code written, no version bumps -- this was a runbook.

CONTEXT.md

@@ -39,12 +39,31 @@ so pruning could only mean deleting a **different** app's only local recovery un
 boxes are Tier 0; the colleague's box carries none of our customer data and is clean-installed shortly.
 So R-176's in-place migration rehearsal is **withdrawn**, not deferred.
 
-**S-14 — prove first, then vouch (2026-08-03).** Golden **0.192.0** is baked, published and verified in
-the registry, and is **deliberately UNVOUCHED**. Vouching is what makes a fresh install pick a golden
-up, so vouching one that no box has been proven from would put an unproven disk layout in front of the
-next install anywhere. The bake script already treats the hub record as a separate deliberate step; this
-makes the ordering a rule. **The remaining work is R-178** — reinstall each demo box from the merged
-golden, prove claim → deploy → back up → restore, **one box at a time**, and only then vouch.
+**S-14 — prove first, then vouch (2026-08-03) — SPENT, and the ordering did not survive contact.** The
+rule was: golden **0.192.0** stays UNVOUCHED until a box has been proven from it, because vouching is
+what makes a fresh install pick a golden up. **In the event the golden was vouched at 07:23:26 CEST on
+2026-08-03, before any box was reinstalled** (hub log `Artifact manifest set: agent=0.119.0
+golden=0.192.0`), so the ordering was already spent when R-178's session opened; the operator elected
+to accept it rather than revert the manifest. **Both boxes were then reinstalled and proven** (R-178,
+`REPORT.md`), so the end state is the intended one and no unproven layout was ever in front of a real
+install — but the rule protected nothing, because nothing enforced it. **The lesson is R-115's, one
+layer up:** an ordering that lives only in a `CONTEXT.md` sentence and a runbook's §7 is a reminder,
+and reminders do not hold. If prove-then-vouch is to be a rule it needs the shape R-120's gate has —
+a refusal at `handleSetArtifacts`, the sole path to `SetArtifactManifest`, which runs without anyone
+choosing to run it.
+
+**S-15 — the merged layout is proven live, by two different supply paths (2026-08-03, R-178).** Both
+demo boxes were wiped and reinstalled from golden 0.192.0 and taken through claim → deploy → back up →
+**restore**. **demo-hp** was installed with `--golden <local volid>` (the layout proof) and
+**demo-felhom** by the normal manifest route with `--force-gitea-golden` (the pipeline proof —
+`verified sha256 54e2a4c431daf580… matches the hub manifest`), deliberately different so the session
+proved the disk shape *and* the delivery route rather than one of them twice. Live shape on both:
+`mp0` at `/var/lib/felhom`, `backup=1`, **no `mp1`**; `/var/lib/docker` and `/mnt/sys_drive` both real
+mounts of its subdirectories via `/etc/fstab`; ONE `df` figure and one device id on all three paths;
+3/3 reboots each with the binds surviving every time. **What is NOT proven is B2** → **R-181**: the
+floor guards `captureAllRecoveryUnits` and not `runVolumeDumps`, which is the leg that fills the
+volume, and its refusal message's "the previous unit is untouched" was measured false. R-165 is
+therefore **IMPLEMENTED**, not PROVEN-LIVE.
 
 **S-11 — D-c's routing, and why R-158's own proposal was overruled (2026-08-02, R-167 SHIPPED).**
 Decision D-c splits two signals by AUDIENCE, and the split is the ruling: **a fill warning is the