docs: REPORT + README — intermediary-mount model (controller half)

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

controller/README.md

@@ -621,6 +621,24 @@ not just those with HDD data. Non-HDD apps can configure destination, method, an
 
 ### 4. Storage Management
 
+> **⚠️ INTERMEDIARY-MOUNT model (v0.67.x, pairs with agent v0.35.x).** External data drives are now
+> visible in the guest at a STABLE path **`/mnt/felhom-drives/<name>`**, NOT the raw `/mnt/<name>`. The
+> agent keeps a single permanent parent bind `/mnt/felhom-drives` in the guest and swaps each drive's
+> `felhom-data` namespace **underneath it host-side** (`mount --bind`), so the guest sees attach/detach
+> **live with no reboot** (mount propagation), the bind source never disappears (C1-immune), and only
+> `felhom-data` crosses in (confinement). The per-drive `pct set -mpN` bind is **deprecated**.
+> - The registered storage path + every app's **`HDD_PATH`** + the FileBrowser source = the stable
+>   `/mnt/felhom-drives/<name>`. The controller maps it back to the raw `/mnt/<name>` (`agentWhere()`)
+>   only for agent calls (assign/attach/eject/decommission). `GET /api/disks` carries `guest_path` +
+>   `bound_under_parent` (the guest-visible signal).
+> - **Drive-absent gate** (`internal/web/intermediary.go`, `driveGateLoop` 30s): an absent
+>   `/mnt/felhom-drives/<name>` drive stops + blocks its apps (`StoppedStacks` = the gate-stopped set);
+>   a returned drive re-attaches + auto-restarts them; `actionStack` refuses to start an app whose drive
+>   is absent ("tárhely nem elérhető"). SSD/system paths are never gated.
+> - **H1 endpoints** `POST /api/storage/{disconnect,reconnect,restart-apps}` drive the host-side
+>   eject/reconnect (no guest reboot). A guest reboot self-converges (`recreateBootStaleApps` recreates
+>   boot-stale drive-backed apps onto the re-propagated drive once the agent re-binds it).
+>
 > **⚠️ Rebuilt on the agent-delegated disk model (v0.43.0), made ROLE-AWARE in v0.44.0, UX-polished in
 > v0.45.0.** After the 8C
 > de-privileging, the controller holds **no Proxmox/disk credentials and no destructive authority** — disk