test(nomercy): Phase 1 partial — 1.1/1.2/1.5/1.12 PASS, 1.3/1.4/1.8 by-design block

Stable-path model: registry stable (1.1), deregister+re-add registers stable not
raw (1.2, the v0.78 path), disk card shows stable+Regisztrálva (1.5 live UI),
free-form raw add rejected/no symptom (1.12). Loop devices refused by agent
block-device whitelist (validate.go:124) -> 1.3/1.4/1.8 inconclusive-by-design;
compensating unit-test + 1.2 coverage noted.

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

@@ -67,6 +67,66 @@ INCONCLUSIVE = could not assert cleanly (reason given).
 
 ## Phase 1 — stable-vs-raw path model — ⏳ IN PROGRESS
 
+**Method:** mix of live-UI (claude-in-chrome on `felhom.demo-felhom.eu`) and exact-endpoint (curl to
+the in-guest controller `127.0.0.1:8080`). The demo controller has **no password set**
+(`authEnabled()=false`), so CSRF is skipped (`csrf.go:30`) and direct POSTs equal the UI's requests
+(no server logic skipped — only browser rendering, which I cover with claude-in-chrome where it matters).
+
+### 1.1 — registry holds only stable paths — ✅ PASS (exact-endpoint + UI)
+- `settings.json` storage_paths = ONLY `/mnt/felhom-drives/{felhom-flash,felhom-usb}`. `GET /api/disks`:
+  both drives `state=attached`, `role=user-data`, `guest_path=/mnt/felhom-drives/<name>`,
+  `bound_under_parent=true`, real sizes (flash 125.7 GB, usb 983 GB). No raw `/mnt/<name>` registry entry;
+  no rootfs placeholder. Wrong outcome (raw entry / placeholder) ruled out.
+
+### 1.2 — deregister → re-add via "Regisztrálás" — ✅ PASS (exact-endpoint = UI request)
+- Deregister-only of felhom-usb via `POST /settings/storage/remove` (the "Eltávolítás" form, field
+  `storage_path`, stable path) → 302; registry left only flash; **drive stayed mounted** at stable
+  (`sdb1[/felhom-data]`) — not ejected; no rootfs placeholder.
+- Re-add via `POST /api/storage/register {where:"/mnt/felhom-usb"}` (the raw `mount_path` the disk-card
+  button sends) → `{ok:true, where:"/mnt/felhom-drives/felhom-usb", raw:"/mnt/felhom-usb"}`. Registry
+  restored to BOTH stable paths; **no raw entry leaked**; **no rootfs placeholder created**. The v0.78 bug
+  (raw registration + "Rendszermeghajtón" placeholder) is ruled out on the exact UI request path.
+
+### 1.3 — attach existing (LOOP_A) — ⚠️ INCONCLUSIVE (by-design block; compensating coverage)
+### 1.4 — init/format+enroll (LOOP_B) — ⚠️ INCONCLUSIVE (by-design block; compensating coverage)
+### 1.8 — wipe (LOOP_A) — ⚠️ INCONCLUSIVE (destructive device-wipe not executed)
+- **Loop devices cannot drive the real init/attach/wipe flow:** the agent refuses non-whitelisted block
+  devices — `POST /api/storage/init {device:/dev/loop1}` →
+  `HTTP 400: storage: refusing to operate on non-whitelisted block device "/dev/loop1"`
+  (felhom-agent `internal/storage/validate.go:124`, `ValidateBlockDevice`; the whitelist is real
+  block-disk patterns only, no dm/loop/symlinks). **This is a SECURITY PASS in its own right** — the
+  agent will not format an arbitrary device the controller names.
+- The only agent-enumerable user-data devices are the two real drives; `felhom-flash` holds ~173 MB of
+  real appdata+backups with **no PBS floor** (mp8 is a bind, excluded from the whole-CT vzdump), so a
+  destructive real-drive wipe is disproportionate to the test value and was **not** performed.
+- **Compensating coverage for the stable-registration these target:** the init/attach paths register via
+  the SAME `registerStoragePath(stablePathForName(path.Base(where)), …)` proven live in 1.2, and the
+  controller unit tests `TestRunStorageInit_Success` / `TestRunStorageAttach_Success` assert registration
+  at `/mnt/felhom-drives/<name>` (and that the agent gets the RAW path) — both green this session.
+  Recommend a future supervised run with a genuinely spare whitelisted disk to close the live gap.
+
+### 1.5 — disk card shows stable path + correct badge — ✅ PASS (live UI, claude-in-chrome)
+- Both cards render the **stable** sub-line (`/mnt/felhom-drives/felhom-flash`,
+  `/mnt/felhom-drives/felhom-usb`), correct device/size (`ext4 · /dev/sdc1[/felhom-data] · Flash Drive`
+  0.2/117.1 GB; `ext4 · /dev/sdb1[/felhom-data] · HD710 PRO` 0.0/915.8 GB), badge **"Regisztrálva"** +
+  "Aktív" — NOT the v0.79 spurious "Nem regisztrált", NOT "Rendszermeghajtón". Action buttons
+  (Leválasztás/Eltávolítás/Leszerelés/Törlés) present and (per source `regKey=guest_path`) carry the
+  stable path. Screenshot captured.
+
+### 1.12 — free-form raw add probe (the parked gap) — ✅ PASS (no symptom reproduced) (exact-endpoint)
+- Raw `/mnt/felhom-flash` does **not exist inside the container** (the raw host mount is never bound into
+  the guest; only the stable parent `/mnt/felhom-drives` is, via mp8 + the `/mnt:rslave` bind). So
+  `POST /settings/storage/add {storage_path:/mnt/felhom-flash}` is **rejected** at validation:
+  "Az útvonal nem létezik vagy nem mappa." (`handlers.go:1264` exists-and-dir; `:1272` is-mountpoint).
+  Registry unchanged (still exactly the 2 stable paths). The free-form-add gap does **not** recreate the
+  "Rendszermeghajtón"/disconnected symptom for a raw drive path.
+- **Observation (not a finding):** the same form WOULD accept `/mnt/sys_drive` (exists + is a mountpoint +
+  writable + non-overlapping) — i.e. a user could free-form-register the system SSD volume as a user-data
+  path. That is consistent with the documented SSD-only fallback (Phase 2.4), not the raw-drive bug; noted
+  for awareness, no symptom.
+
+### 1.6 / 1.7 / 1.9 / 1.10 / 1.11 — ⏳ pending (need a deployed drive-backed app)
+
 ## Phase 2 — /mnt/sys_drive third volume — ⏳ PENDING (2.3 PASS captured)
 
 ## Phase 3 — server restart + retired banner — ⏳ PENDING