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.

scripts/CHANGELOG.md

@@ -1,3 +1,32 @@
+## docs — v1.22.0 exercised end to end on two real reinstalls (2026-08-03, R-178) — **no script change**
+
+**Nothing shipped.** `felhom-host-install.sh` stayed at **v1.22.0**; the published copy at
+`https://felhom.eu/scripts/felhom-host-install.sh` was confirmed byte-identical to the repo copy
+(`sha256 ed02acb2da46c8d2b5c486ce99d5b9a2747e8786c6eb03652cf755ed1abdd9f4`) before use. Both demo
+boxes were uninstalled and reinstalled with it, by **two deliberately different supply paths**:
+demo-hp with `--golden <local volid>` (the `:2584` alternative), demo-felhom with
+`--force-gitea-golden` (the canonical C.3 customer command). The merge-aware `step_grows` produced
+`data +46G (->70G, ONE volume)` and `+226G (->250G)` respectively, and `fetch_verify` was observed
+succeeding against the vouched manifest for **both** artifacts on demo-felhom
+(`verified sha256 a7763d31b55b5ce7…` agent, `verified sha256 54e2a4c431daf580…` golden).
+
+**Two script-side findings, filed not fixed** (the session was a runbook; §7 forbade code):
+
+- **R-180** — `--archive-storage` is validated for existence (`:1583`) and for golden resolution
+  (`:1661`), but never against the ACL storage set it is about to grant (the fixed default
+  `local local-lvm felhom-pbs`). Staging the golden on `felhom-backup` therefore passed every
+  pre-flight gate and died at **step 8/8**: `HTTP 403: permission denied at /storage/felhom-backup
+  (missing privilege Datastore.AllocateSpace)` — *after* step 2 minted the token, step 4b **rotated
+  and vaulted root@pam**, and step 5 installed the agent. `ARCHIVE_STORAGE ∈ PVE_STORAGES` is a
+  one-line assertion over two variables both known at `:1583`.
+- **R-179** — `--uninstall` leaves the NAS network-storage systemd units behind
+  (`mnt-felhom\x2ddrives-<share>.{mount,automount}`; automount left `failed`, parent bind left
+  mounted). The Part E residue-diff provenance is from **v1.9.1**, which predates the feature — and
+  demo-felhom, which never had a share configured, left nothing, which is exactly why a diff on such
+  a box reported clean.
+
+Full evidence: root `REPORT.md`.
+
 ## host-install: one data volume, derived from the disk (2026-08-03, R-165)
 
 **Forced by a census, not planned.** `felhom-agent` v0.120.0 merges the appliance's two data volumes