test(nomercy): Phase 4 part 1 — host reboot (4.1/4.2/4.5); F3 onboot=0, F4 double-bind

4.1 plain host reboot: drives re-bind by UUID at stable, sys_drive separate, apps
recreate, registry stable. FINDING F3: 9201 onboot=0 -> did NOT auto-start (whole
guest down until manual pct start). 4.2 REAL sdb<->sdc swap, drives still map by
UUID to correct stable path (v0.37 ruled out). 4.5 double-bind stable at 2x (not
leaking); FINDING F4 pre-existing 2x bind.

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

documentation/tests/TEST-REPORT-stable-path-sysdrive-restart-2026-06-23.md

@@ -287,6 +287,39 @@ Pre-host-reboot capture: `sdb1`=`da9e7089`(usb), `sdc1`=`81a26531`(flash); `onbo
 `felhom-agent` service `enabled` (will auto-start on host boot). navidrome on flash, radarr on sys_drive.
 **Prediction:** with `onboot: 0`, 9201 will NOT auto-start after the host reboot (candidate finding F3).
 
+### 4.1 — plain felhom-pve host reboot — ✅ PASS (drives/apps/registry) + ⚠️ FINDING F3 (no auto-start)
+- Issued `reboot` on felhom-pve; host returned (fresh boot, ~90 s). `felhom-agent` auto-started (`active`).
+- ⚠️ **FINDING F3 (moderate, pre-existing config): `9201` did NOT auto-start — it was `stopped` after the
+  host reboot** because `pct config 9201` has **`onboot: 0`**. A managed customer guest should come back on
+  its own after a host power-loss/reboot; as configured, the customer's entire home-server (all apps + the
+  controller) stays **down until someone manually `pct start`s it**. *Fix direction:* the golden/provision
+  path should set `onboot: 1` (+ a sensible `startup`/boot-order) on the customer guest; audit whether any
+  provisioned guest has `onboot:1`. (I started 9201 manually to continue.)
+- After manual `pct start 9201` (controller healthy ~5 s): drives re-bound by the agent reconcile **by
+  durable-id** (`uuid:81a26531` flash, `uuid:da9e7089` usb) at the **stable** paths; **sys_drive separate**
+  (`disk--2`); **all apps recreated** (navidrome on flash, radarr on sys_drive, both healthy); **no rootfs
+  placeholders**; **registry stable**. Wrong outcomes (raw/placeholder, sys_drive non-separate, registry
+  drift) ruled out (modulo F3 auto-start).
+
+### 4.2 — /dev reshuffle (sdb↔sdc) — ✅ PASS (REAL swap, not just code-path)
+- The host reboot **genuinely swapped the kernel letters**: before `sdb1`=da9e7089(usb)/`sdc1`=81a26531(flash);
+  after `sdb1`=**81a26531(flash)**/`sdc1`=**da9e7089(usb)**. Despite the swap, the agent bound each drive by
+  **fs-UUID**: `felhom-flash` (81a26531, now sdb1) at `/mnt/felhom-drives/felhom-flash`; `felhom-usb`
+  (da9e7089, now sdc1) at `/mnt/felhom-drives/felhom-usb`. Each NAME mapped to its **own** UUID at the
+  correct stable path — the v0.37 wrong-physical-device regression is ruled out **on a real letter swap**.
+
+### 4.5 — double-bind churn — ✅ PASS (stable, not leaking) + ⚠️ FINDING F4 (pre-existing 2×)
+- Across the host reboot + multiple 20 s reconcile ticks, each drive's bind count held **stable at 2**
+  (`grep -c` on `/proc/mounts`, guest AND host) — it did **not** accumulate to 3,4,… so the "binds leak"
+  wrong outcome is ruled out.
+- ⚠️ **FINDING F4 (minor, pre-existing): each enrolled drive is double-bound** — two identical
+  `/dev/sdXN /mnt/felhom-drives/<name> ext4 …` entries in `/proc/mounts`. The agent logs
+  `guest-attach: drive bound under shared parent (normalized to one bind … prior_binds=2)`, i.e. it detects
+  2 prior binds but the steady state is still 2, so the "normalize to one" isn't fully effective. Matches
+  the documented pre-existing double-bind (the v0.36.x peer-group area); stable, not a leak, no data impact.
+  *Fix direction:* make the normalize-to-one path converge to a single bind (or stop the duplicate
+  rbind at its source).
+
 ## Phase 5 — restore to clean baseline — ⏳ PENDING
 
 ---