docs: §D supervised reboot — F2-a + F2-b live-validated (both findings CLOSED)

F2-a red-proof PASS: parent came up own peer group (shared:94, not
shared:1), no doubling, guest sees both drives. F2-b PASS: reboot with the
exact snapshot-delete stuck state → agent auto-recovered (unlock → removed
real dangling vzdump snapshot → started CT). Zero spurious pages. Two
live-caught fixes noted (?source=active, AllowWarnings).

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

CHANGELOG.md

@@ -32,6 +32,18 @@ Closes the two host-reboot findings from `TESTRUN-fullstack-2026-06-29.md`.
   - Tests: a stale-script/current-unit case triggers reinstall (the F2-a regression); both-current is a
     no-op; missing files are stale; a content guard asserts the shipped script keeps `make-private`.
 
+- **Live-caught fixes (same version, found during felhom-pve validation):** PVE 9.x rejects
+  `GET /nodes/{node}/tasks?running=1` (HTTP 400 "property not defined in schema") — the invariant guard
+  now uses `?source=active`. And the unprivileged-LXC start emits a benign `WARNINGS: 1` (systemd-nesting)
+  advisory that false-failed the recovery's start — `Start` now uses `AllowWarnings` (matching the
+  restore-test's start step).
+- **§D supervised reboot — both findings live-validated.** F2-a: after reboot `/mnt/felhom-drives` came
+  up as its OWN peer group (`shared:94`, not `shared:1`) with no doubling; guest sees both drives, apps
+  healthy. F2-b: a reboot with the exact stale state (induced `snapshot-delete` lock + a real dangling
+  `vzdump` snapshot) reproduced the stuck symptom (pve-guests "CT is locked (snapshot-delete)" → start
+  failed) and the agent auto-recovered — unlock → removed the real dangling snapshot → started the CT.
+  Zero spurious operator pages on the reboots. See
+  `felhom.eu/documentation/audits/TESTRUN-fullstack-2026-06-29.md`.
 - Version `0.48.0 → 0.49.0`.
 
 ## v0.48.0 — report the served local-API leaf fingerprint (hub-side re-key detection, Part A) (2026-06-29)

REPORT.md

@@ -27,9 +27,15 @@ snapshot-delete and start go through the API token; only `pct unlock` shells out
 unlocked-but-not-started; delsnapshot only when a snapshot exists; **invariant guard** (live backup → not
 cleared; unconfirmable → fail-safe); already-running → not restarted; nil controller → no-op.
 
-**Live (B.3).** Simulated stale state on a scratch guest (lock + dangling `vzdump` snapshot) → agent
-restart auto-recovered (unlock + delsnapshot + start). The real reboot-during-backup is the §D supervised
-step.
+**Live (B.3 + §D).** Simulated stale state on scratch 9999 → agent restart auto-recovered (unlock +
+start); the **invariant guard was proven against a REAL in-flight 9201 backup** (left its lock alone). Then
+the **§D supervised reboot** validated the genuine path: a reboot with the EXACT F2-b state (induced
+`snapshot-delete` lock + a real dangling `vzdump` snapshot) reproduced the stuck symptom (pve-guests *"CT
+is locked (snapshot-delete)"* → *"Starting CT 9201 failed"*), then the agent auto-recovered — `clearing a
+stale backup lock` → **`removed dangling vzdump snapshot`** (the real delsnapshot path) → `started CT`. 9201
+running, lock cleared, snapshot deleted, no error. Two live-caught bugs fixed en route: PVE 9.x rejects
+`?running=1` (→ `?source=active`); the LXC-start `WARNINGS: 1` nesting advisory false-failed the start
+(→ `AllowWarnings`).
 
 ## F2-a — shared-parent boot script never redeployed (Part C)
 
@@ -49,8 +55,11 @@ parent its own peer group.
 **Tests.** Stale-script/current-unit → reinstall (the F2-a regression); both-current → no-op; missing →
 stale; content guard that the shipped script keeps `make-private`.
 
-**Red-proof (C.1).** Requires a reboot — the §D supervised step: parent must come up as its own group
-(not `shared:1`) AND the guest must still see both drives (`bound_under_parent=true`).
+**Red-proof (C.1) — PASSED (§D reboot).** `/mnt/felhom-drives` came up as its **own peer group
+`shared:94`** (NOT root's `shared:1`) with **exactly 1 host bind per drive** (doubling gone, was 2); the
+guest still sees both drives (`bound_under_parent=true`; apps healthy). Consistent across two reboots.
+(Separate pre-existing, harmless observation: the guest shows 2 mounts per drive — two parent mounts, same
+`/felhom-data` source, correctly `master:`-slaved; not a regression of this host-side fix.)
 
 ## Green gate