docs: live-activation finding (host inject blocked on unprivileged LXC) + decision

Evidence-based: pct set won't hot-apply to a running guest; /proc/pid/root inject
blocked by mount-locking; nsenter -m loses the host source. Decision: enroll
persists (no forced reboot) + user-triggered batched restart button + P3 flags
"restart to reconnect". Staging-mp deferred. Remaining build noted in REPORT.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

REPORT.md

@@ -34,17 +34,25 @@ After `guest-attach` + a guest restart to activate mp0:
 - Banner cleared: **`[PASS] Storage paths: 1 connected, 0 disconnected`**.
 - `go test ./...` green (both repos).
 
-## KNOWN LIMITATION — live activation (decision needed before P3)
-`pct set` does **not** hot-apply a mountpoint to a *running* guest when the guest's `/mnt` is rshared
-(the P2B rbind shadows the live hotplug; the spike's live hot-apply worked only because `/mnt` wasn't
-yet shared). So a drive enrolled into a **running** guest activates on the **next guest restart** — the
-end-state is correct, but live enroll isn't seamless. This is a genuine hotplug-vs-propagation fork
-(like the chown/idmap + Model A decisions) to settle before P3: options are (a) enroll triggers a guest
-reboot; (b) drop the guest `/mnt` rbind and have enroll do `pct set` (live hotplug works) + a
-lightweight controller-container restart to capture it; (c) let P3 self-heal reconcile drive activation.
-Fresh guests from the rebaked golden are unaffected (mp mounts activate at first boot, before the
-controller starts).
+## LIVE-ACTIVATION — investigated, mechanism chosen (evidence-based)
+A drive enrolled into a **running** unprivileged guest cannot be activated live, and the host-side
+bind-inject is **blocked** (proven on 9201): `pct set` doesn't hot-apply a mountpoint to a running
+guest; `/proc/<pid>/root/...` bind → `mount: bad superblock` (unprivileged mount-locking); `nsenter -m`
+into the guest ns loses the host source path. The bind activates at the **next guest boot** (validated:
+reboot → mp0 active `/dev/sdb1[/felhom-data]`, controller sees it, banner clears). Fresh guests from the
+rebaked golden are unaffected (mp activates at first boot, before the controller starts).
 
-## Not done (next phases)
-P3 self-heal watchdog reconcile (4-state new/enrolled/ejected/decommissioned) + safety rails; P4
-dual-role + backup-aware wipe warning. Cross-drive backup ENGINE remains out of scope.
+**Decision (Viktor):** enroll persists via `pct set` with **NO forced reboot**; the UI shows a
+"pending activation" state + a user-triggered **"Újraindítás most (~30s)"** button that batches all
+pending drives; P3 self-heal flags "restart to reconnect" for recovered drives. The staging-mp
+live-propagation alternative is deferred to its own spike. (Build remaining — see below.)
+
+## Not done (next build increments)
+- **Activation-UX:** agent self-reboot endpoint (`POST /guest/reboot` → `pct reboot <vmid>`, token-
+  scoped) the controller calls; controller "pending activation" detection (registered + agent shows the
+  drive present/attached, but not a live mount in the container) + a batched "Újraindítás most (~30s)"
+  button.
+- **P3** self-heal watchdog reconcile (4-state new/enrolled/ejected/decommissioned, durable-id-keyed) +
+  safety rails (flapping backoff, durable-id-only, in-progress-op respect, PVE coordination,
+  re-propagate); flags "restart to reconnect".
+- **P4** dual-role eligibility + backup-aware wipe warning. Cross-drive backup ENGINE stays out of scope.