v0.95.0: enrollment wizards use the raw-device scan /disks/candidates (Impl-2b)

Both wizards now source candidates from the agent's Impl-2a raw-device scan
(GET /disks/candidates, proxied) instead of the Observe-based /api/disks — so a
brand-new non-PVE-storage drive is finally discoverable + enrollable end-to-end.
agentapi.ListCandidates + a passthrough proxy (no controller-side filtering; the
agent's unclaimed filter is authoritative). storage_init renders `initialize`,
storage_attach renders `attach`; the enroll flow + Impl-1 guarded mkfs unchanged.
Tests + go build/vet/test clean.

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

controller/README.md

@@ -852,6 +852,17 @@ not just those with HDD data. Non-HDD apps can configure destination, method, an
 
 The storage subsystem handles the full lifecycle of external storage: detection, initialization, path registration, and data migration.
 
+> **CURRENT (post-de-privileging + Impl-2b, v0.95.0):** the in-guest storage code below
+> (`internal/storage/scan.go`, `format.go`, `attach.go`) is **retired** — all disk ops are delegated to
+> the host agent via `internal/agentapi`. The two enrollment wizards (`/settings/storage/init`,
+> `/settings/storage/attach`) now populate candidates from the agent's **raw-device scan**
+> (`GET /api/disks/candidates` → agent Impl-2a, proxied by `agentDiskCandidatesHandler`): `initialize` =
+> every unclaimed disk (blank or data-bearing), `attach` = the mountable-FS subset. The agent's
+> unclaimed-disk filter (Impl-1 `claim.go`) is authoritative + fail-safe (never offers OS/enrolled/claimed
+> disks), so the controller does NO client- or server-side filtering. Enrollment posts to the unchanged
+> `/api/storage/init` (format via the agent's Impl-1 guarded `mkfs` → mount → bind → intent) or
+> `/api/storage/attach` (mount + bind, no format). The legacy text below is kept for historical context.
+
 #### Disk Scanning (`internal/storage/scan.go`)
 
 - `ScanDisks()` uses `lsblk -J -b` for block device enumeration