test(nomercy): Phase 1 complete — stable-path model holds; F1 restic dead-weight

1.6 deploy/HDD_PATH stable, 1.7 eject clean stable removal (v0.80 ruled out) +
impact names apps, 1.9 migrate flips stable->stable w/ verify-before-cleanup,
1.10 decommission via raw agentWhere + reconnect restore, 1.11 backups under
stable namespace. FINDING F1: restic binary still apt-installed (Dockerfile:58)
though all restic code moved to agent — dead weight. navidrome now on flash.

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

@@ -125,7 +125,67 @@ the in-guest controller `127.0.0.1:8080`). The demo controller has **no password
   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)
+### 1.6 — deploy app onto a drive → HDD_PATH stable — ✅ PASS (exact-endpoint = UI deploy)
+- Deployed **navidrome** (lightest drive-backed app, 256M) via `POST /api/stacks/navidrome/deploy`
+  `{values:{DOMAIN,SUBDOMAIN:navtest,HDD_PATH:/mnt/felhom-drives/felhom-usb}}` → healthy. `app.yaml`
+  `HDD_PATH=/mnt/felhom-drives/felhom-usb` (stable). Container media bind
+  `/mnt/felhom-drives/felhom-usb/userdata/media/music → /music` (stable drive namespace, dir 2775 g1000).
+  Data not on rootfs; HDD_PATH not raw. (navidrome's config/DB is a named Docker volume on the docker-data
+  disk by catalog design — only its media is drive-bound.)
+
+### 1.7 — eject removes the stable entry cleanly + impact names apps — ✅ PASS (exact-endpoint)
+- **Impact:** `GET /api/storage/impact?where=/mnt/felhom-drives/felhom-usb` → `apps:["Navidrome"]`;
+  felhom-flash → `apps:[]`. Names the right apps (wrong outcome "no apps when an app uses it" ruled out).
+- **Eject** (Leválasztás) on felhom-flash (no app, reversible): agent ejected the **raw** `/mnt/felhom-flash`
+  (mapped from stable via `agentWhere`); registry left ONLY felhom-usb — the felhom-flash **stable** entry
+  removed **cleanly, no orphan** (the v0.80 bug ruled out); bind detached, raw host mount preserved.
+  Restored via `POST /api/storage/register` → re-registered stable + re-bound (`sdc1[/felhom-data]`).
+
+### 1.8 — wipe — ⚠️ INCONCLUSIVE (see 1.3/1.4 — no safe whitelisted target; device-wipe not executed)
+- The wipe's confirm/impact GATE is otherwise exercised: `handleStorageWipe` requires
+  `mount_name == path.Base(where)` (storage_handlers.go:558) and ejects via `agentWhere` then formats via
+  the agent's two-step confirm — the same mapping proven in 1.7/1.10. The destructive `mkfs` itself was not
+  run (loop blocked by the whitelist; real drives hold un-floored data).
+
+### 1.9 — migrate-app flips HDD_PATH stable→stable — ✅ PASS (exact-endpoint)
+- `POST /api/storage/migrate-app {app:navidrome, target:/mnt/felhom-drives/felhom-flash}` → job ran
+  validate→copy→verify→flip→**cleanup** (phase=done, unit `cleaned`). navidrome `HDD_PATH` flipped to
+  `/mnt/felhom-drives/felhom-flash` (stable); media bind now on flash; navidrome healthy; **no raw leak**;
+  source cleaned only AFTER verify. Wrong outcomes (source deleted before verify / HDD_PATH left raw/old)
+  ruled out. (navidrome now lives on felhom-flash — removed in Phase 5.)
+
+### 1.10 — self-serve decommission → agent op via raw + app missing storage — ✅ PASS (exact-endpoint)
+- `POST /api/storage/decommission {where:stable-usb, mode:anyway, mount_name:felhom-usb}` →
+  `{decommissioned:true, stopped_apps:["Navidrome"]}`. Agent intent `da9e7089→decommissioned`; agent log
+  shows the op on the **RAW** path (`where=/mnt/felhom-usb`, `guest-detach … fully unmounted`) — wrong
+  outcome (agent called with the unmapped stable path) ruled out. navidrome gate-stopped.
+- Restored: `POST /api/storage/reconnect` → `{reenrolled:true, restarted:["navidrome"]}`, intent→enrolled,
+  re-bound at stable, navidrome healthy.
+
+### 1.11 — backup lands under the stable namespace — ✅ PASS (path-correctness) + FINDING (restic) (exact-endpoint)
+- `POST /api/backup/run` (the app-data **DB-dump** backup) ran successfully; for navidrome it correctly
+  found **0 databases** (no DB container — SQLite in a named volume), a no-op success, not a failure.
+- **Path correctness:** all existing backup artifacts live under the **stable** namespace
+  `/mnt/felhom-drives/felhom-flash/backups/primary/<app>/` (recovery units: `compose/` + `manifest.json`),
+  never a raw/rootfs path. Wrong outcome (backup under raw/rootfs) ruled out.
+- ⚠️ **FINDING F1 (minor, pre-existing): the prompt's "restic repo" premise is stale, and the restic
+  binary is dead weight in the image.** Disk-tier restic backup was moved to the host agent in the
+  de-privileging; the controller source no longer execs restic (all references are "moved to agent"
+  comments + vestigial `config.go` `ResticPasswordFile/Schedule` fields + the `settings.go`
+  `migrateResticToRsync` one-way migration). **But `Dockerfile:58` still `apt install`s `restic`** (and
+  line 42 comments "for backup operations"), so `/usr/bin/restic` ships in the controller image unused.
+  *Fix direction:* drop `restic` from the Dockerfile install list (and the dead `Restic*` config fields)
+  to shed image weight + remove a confusing "disk-tier is still here" signal. Not a functional bug.
+- **Observation:** a named-volume app (navidrome) deployed onto a drive created **no** `appdata/` or
+  `backups/` namespace nor a recovery unit on that drive (only the shared `userdata/` skeleton). Recovery
+  units appear keyed to appdata-bind apps; named-volume-only apps rely on the DB-dump/volume-tar path
+  instead. Flagged for awareness; likely by-design, not verified as a bug.
+
+**Phase 1 verdict:** the stable-vs-raw path model holds across register/deregister/disk-card/eject/
+decommission/migrate/backup. The v0.78 (raw register), v0.79 (spurious unregistered badge), and v0.80
+(orphaned stable entry on eject) bugs are all ruled out live. The only gaps are the loop-device
+init/attach/wipe (blocked by the agent's block-device whitelist — a safety PASS) and the restic dead-weight
+finding (F1).
 
 ## Phase 2 — /mnt/sys_drive third volume — ⏳ PENDING (2.3 PASS captured)