audit: §D supervised reboot done — F2-a + F2-b red-proofs PASS (findings closed)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0162BnMpUXscPsUB1cU8Tr6K

documentation/audits/TESTRUN-fullstack-2026-06-29.md

@@ -280,7 +280,7 @@ surfaced by live validation and fixed: PVE 9.x rejects `?running=1` (→ `?sourc
   and self-cleared. (Note: PVE reserves the snapshot name `vzdump`, so a dangling one can't be hand-made
   — the delsnapshot-against-a-real-snapshot path is unit-tested and live-fires in the §D real reboot.)
 
-### Part C — host-side doubling (F2-a) — **root cause FOUND; deploy fix shipped; red-proof pending §D**
+### Part C — host-side doubling (F2-a) — **root cause FOUND; fix shipped; red-proof PASSED (§D)**
 Reproduced the exact pathology in a scratch dir at `/mnt` (where the live parent lives): the **stale**
 sequence (`bind + make-shared`, no `make-private`) leaves the self-bind in root's `shared:1` → sub-bind
 count **2** (doubling); the **correct** sequence (`bind → make-private → make-shared`) gives an own group
@@ -290,21 +290,33 @@ count **2** (doubling); the **correct** sequence (`bind → make-private → mak
 `sharedParentInstallStale` compares **both** the script and the unit. Boot-time-only — it rewrites the
 on-disk script; it does **not** churn the live mount (still guarded on `!isHostMountpoint`).
 - **Deploy fix proven:** on the v0.49.0 startup the corrected script (with `make-private`) was installed
-  to `/usr/local/sbin/felhom-shared-parent.sh` (sudo log shows the install). The live mount is left
-  untouched (`/mnt/felhom-drives` still `shared:1`, doubled — by design, until the next boot).
-- **PENDING (§D, supervised):** the red-proof requires a reboot — the parent must come up as its **own**
-  peer group (≠ `shared:1`) AND the guest must still see **both** drives (`bound_under_parent=true`). Held
-  for a supervised window per the task's STOP rule (no unsupervised reboot / live mount-propagation change).
+  to `/usr/local/sbin/felhom-shared-parent.sh` (sudo log shows the install). The live mount was left
+  untouched until the reboot (`/mnt/felhom-drives` still `shared:1`, doubled — by design).
+- **RED-PROOF PASSED (§D, two reboots):** `/mnt/felhom-drives` came up as **`shared:94`** — its OWN peer
+  group, NOT root's `shared:1` — and each drive has **exactly 1 host bind** (doubling GONE; was 2 each).
+  The guest still sees both drives (`bound_under_parent=true`; apps all healthy). Consistent across both
+  reboots. (Separate, pre-existing, harmless observation: the GUEST shows 2 mounts per drive — two parent
+  mounts in the guest namespace, same `/dev/sdX1 /felhom-data` source, `master:` slaved correctly; NOT a
+  regression of this fix, which only corrected the host parent's peer group. Worth a future look.)
 
-### §D — supervised host reboot — PENDING (not run unsupervised)
-Validates, in one window: **B** (start a vzdump of 9201 → reboot mid-backup → agent auto-recovers the
-locked CT, the real delsnapshot path) and **C** (parent own-group + guest sees both drives). Per the task's
-strict rule, NOT run autonomously.
+### §D — supervised host reboot — DONE (PASS)
+Run in a supervised window (user-authorized). Two reboots:
+1. **Reboot mid-backup (caught the `backup`/tar phase):** PVE auto-cleared the `backup` lock and started
+   9201 normally (no stuck symptom in that phase); the agent recovery saw no lock → correctly skipped.
+   The C red-proof passed (parent `shared:94`, no doubling). A real `vzdump` snapshot remained.
+2. **Reboot with the EXACT F2-b state** (induced `lock: snapshot-delete` + the real dangling `vzdump`
+   snapshot from reboot 1): pve-guests **FAILED** to start the locked CT — *"starting CT 9201: CT is
+   locked (snapshot-delete)"* → *"Starting CT 9201 failed"* — the genuine stuck symptom. The agent then
+   auto-recovered: `clearing a stale backup lock` (lock=snapshot-delete) → **`removed dangling vzdump
+   snapshot`** (the real delsnapshot path) → `started CT after clearing the stale lock (onboot)`. 9201
+   running, lock cleared, snapshot deleted, no error (the `?source=active` + `AllowWarnings` fixes held).
+**Zero spurious operator pages** across both reboots (no host_down/stale/capability/leaf events — only the
+controller's benign notification-prefs re-register). The interrupted-backup temp `.dat` was cleaned.
 
-### Final parity (post-fix) — known-good
+### Final parity (post-fix, post-§D) — known-good
 agent **v0.49.0** / controller v0.91.0 / hub v0.22.1 (+ operator-email hub-config); leaf==pin `60b5974d…`;
-caps **46/46**; both drives bound + apps healthy; channel up; scratch guest 9999 back to baseline; the
-scratch deny removed + `/etc/sudoers` valid; 9201 backup completed + lock self-cleared. **Persistent until
-the §D reboot:** the F2-a host-side doubling (the corrected boot script is staged; live mount intentionally
-untouched). No secrets recorded (tokens read out-of-band, never printed; leaf fps + the operator email are
-not secret).
+caps **46/46**; `/mnt/felhom-drives` is its **own peer group `shared:94`** with **no doubling** (1 bind
+each); both drives bound + 12 healthy containers; scratch guest 9999 back to baseline; the scratch deny
+removed + `/etc/sudoers` valid; 9201 lock cleared + dangling snapshot deleted. **Both findings F2-a and
+F2-b are now CLOSED and live-validated.** No secrets recorded (tokens read out-of-band, never printed;
+leaf fps + the operator email are not secret).