REPORT: v0.78.0 deployed to 9201 + registry remediated — drives now register at the stable path, 2 connected, badge+banner gone

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

REPORT.md

@@ -32,18 +32,38 @@ banner. The real drives were fine the whole time.
 - `internal/web` test count: +1 (the new register test). Full suite green.
 
 ## Deploy (v0.78.0 → guest 9201)
-- _(filled at deploy)_ built+pushed `gitea.dooplex.hu/admin/felhom-controller:0.78.0` on 192.168.0.180;
-  deployed to 9201 (pull → `/etc/felhom-controller-image` → restart `felhom-controller-bootstrap.service`);
-  `docker ps` → `:0.78.0 Up (healthy)`.
+- Built + pushed `gitea.dooplex.hu/admin/felhom-controller:0.78.0` on 192.168.0.180 (`build.sh 0.78.0
+  --push`, 142M). Deployed to 9201: `docker pull` → `printf … > /etc/felhom-controller-image` → restart
+  `felhom-controller-bootstrap.service`. `docker ps` → `:0.78.0 Up (healthy)` (was `:0.77.0`).
 
-## 9201 registry remediation (non-destructive)
-- _(filled at remediation)_ deregistered the two raw entries `/mnt/felhom-flash` + `/mnt/felhom-usb`
-  (deregister-only — NOT eject, the live drive stays mounted), removed the empty rootfs placeholder dirs,
-  re-registered via the fixed `POST /api/storage/register` → both now at `/mnt/felhom-drives/<name>`.
+## 9201 registry remediation (non-destructive — drive never unmounted)
+The registry held the two stale RAW entries `/mnt/felhom-flash` + `/mnt/felhom-usb`. Remediated through
+the real server pipeline:
+1. Re-registered both via the FIXED `POST /api/storage/register` (in-guest `docker exec … curl
+   127.0.0.1:8080`; auth+CSRF skipped, no password set) → response `where=/mnt/felhom-drives/felhom-flash`
+   (+`raw=/mnt/felhom-flash`) and `…/felhom-usb` — confirming the fix end-to-end.
+2. Deregistered the two raw entries via `POST /settings/storage/remove` (deregister-only — `RemoveStoragePath`,
+   **NOT** eject; the host drive mounts were never touched). Registry now holds ONLY the two stable paths.
+3. Removed the orphaned rootfs placeholder trees `/mnt/felhom-flash` + `/mnt/felhom-usb` in the guest
+   (verified 0 files — only an empty userdata skeleton from the buggy raw registration — and verified NOT
+   mounts before `rm -rf`). Guest `/mnt` now: `felhom-drives` + `sys_drive` only.
 
-## Verification (§6-C)
-- _(filled at verify)_ registry holds the stable paths; controller selftest storage paths CONNECTED;
-  storage UI shows real size/device, **no "Rendszermeghajtón"** badge, **no activation banner**.
+## Verification (§6-C) — server-side pipeline + rendered page (NOT browser)
+- **Registry:** `settings.json` `storage_paths` = `/mnt/felhom-drives/felhom-flash` +
+  `/mnt/felhom-drives/felhom-usb` (stable only).
+- **Selftest:** `[PASS] Storage paths: 2 connected, 0 disconnected` (was `[WARN] 0 connected, 2
+  disconnected`); `[PASS] System data path: /mnt/sys_drive`.
+- **Per-path device resolution (what the UI renders):** `/mnt/felhom-drives/felhom-flash` →
+  `/dev/sdc1[/felhom-data] 117.1G`; `/mnt/felhom-drives/felhom-usb` → `/dev/sdb1[/felhom-data] 915.8G` —
+  both a DIFFERENT block device from `/` (`overlay`), so the system-drive check is false.
+- **Rendered `/monitoring` HTML** (the bytes the browser renders): "aktiválásra vár" banner = **0
+  occurrences**; "Rendszermeghajtón" badge = **0 occurrences**; storage bars show `felhom-flash` /
+  `felhom-usb` at `117 GB` / `916 GB`.
+- **Method:** verified via the controller's server-side selftest + the exact server-rendered page HTML +
+  the per-path device resolution the page calls — NOT claude-in-chrome. The only residual is the
+  browser's visual render of that verified HTML.
+- **Regression:** the correct `runStorageInit`/`runStorageAttach` paths are unchanged (unit tests green);
+  not re-run live to avoid mutating a real drive.
 
 ## Observations (recorded, NOT acted on)
 1. `pendingActivationDrives` (`storage_handlers.go`) keys `attached` by the agent's raw `MountPath` and