controller v0.45.0: storage UX polish — deterministic order, init filter, register shortcut, system-storage clarity

B1 sort /api/disks (user-data→system→backup, alpha within); B2 init wizard
excludes mounted drives; B3 Regisztrálás primary action for mounted-unregistered
user-data drives (POST /api/storage/register); B4 per-card purpose descriptions +
app-backing tags + tiering note (local & local-lvm both kept); B5 eject already
names affected apps. Pairs with felhom-agent v0.24.0 eject role-gate.

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

controller/README.md

@@ -514,7 +514,8 @@ not just those with HDD data. Non-HDD apps can configure destination, method, an
 
 ### 4. Storage Management
 
-> **⚠️ Rebuilt on the agent-delegated disk model (v0.43.0), made ROLE-AWARE in v0.44.0.** After the 8C
+> **⚠️ 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
 > execution + the gate live entirely in the **host agent**. The drive UI is driven by the agent's
 > authoritative **role** (`system` | `backup` | `user-data`, from `GET /api/disks`): the appliance's own
@@ -526,6 +527,17 @@ not just those with HDD data. Non-HDD apps can configure destination, method, an
 >   Biztonsági mentés — védett / Felhasználói adat) and registered state, plus a **capacity bar** (the
 >   monitoring `system-bar`, from the agent's `total_bytes`/`used_bytes`). Eject/Wipe render **only** for
 >   user-data drives mounted under `/mnt`.
+>   - **(v0.45.0) Deterministic order** — `agentDisksListHandler` sorts the list server-side
+>     (`sortDisksForView`): **user-data → system → backup** (then unrecognized), alpha by name within a
+>     tier, so it no longer reorders on each reload (the agent's view iterates an unordered Go map).
+>   - **(v0.45.0) Purpose + app-backing clarity (B4)** — `local` and `local-lvm` are both shown (not
+>     collapsed); each card carries a plain-Hungarian **purpose description** keyed on the agent's
+>     role/type, the app-backing storages are tagged (`local-lvm` → "Alkalmazás-rendszer"; user-data →
+>     "Alkalmazás-adatok"), and a one-line tiering note above the list answers "which storage do the
+>     apps use?". Pure presentation — role/type stay authoritative from the agent.
+>   - **(v0.45.0) Register shortcut (B3)** — a mounted, **unregistered** user-data drive offers
+>     **Regisztrálás** as its PRIMARY action: `POST /api/storage/register` → `registerStoragePath` records
+>     the existing mount (no format, no eject) + FileBrowser-syncs. Leválasztás/Törlés stay secondary.
 > - **Customer wipe/eject** — a **type-to-confirm** modal that names the deployed apps that break
 >   (`GET /api/storage/impact` → `appsUsingPath`) and disables the destructive button until the **mount
 >   name is typed exactly**. Wipe (`POST /api/storage/wipe`): eject (unmount + deregister) → server-side
@@ -538,7 +550,10 @@ not just those with HDD data. Non-HDD apps can configure destination, method, an
 >   only if a protected device somehow reaches init.
 > - **Guided attach** (`/settings/storage/attach`, `POST /api/storage/attach`): non-destructive — resolve
 >   the existing fs UUID → `assign` → register. Selector restyled to cards (user-data only).
-> - **Eject** (`POST /api/storage/eject`): benign unmount + deregister, with the agent's dependent-guest warning.
+> - **Eject** (`POST /api/storage/eject`): benign unmount + deregister, with the agent's dependent-guest
+>   warning + the affected-app list (parity with wipe). **The eject is ROLE-GATED at the agent** (felhom-
+>   agent v0.24.0): `POST /disks/eject` refuses to unmount a system/backup mount — the UI hiding the button
+>   is defense-in-depth, not the control. Only user-data mounts are ejectable.
 > - **`agentapi`** (`internal/agentapi`) is the pinned client to the agent local API: `Disks`/`AssignDisk`/
 >   `EjectDisk`/`FormatDisk(…, confirmed, durableID)`; `DiskInfo.role`+capacity;
 >   `FormatResult.{role,needs_confirmation,durable_id}`; `ErrNeedsConfirmation` (user-data) vs