v0.44.0: role-aware drive management — protected lockout + customer type-to-confirm wipe + drive-list restyle

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

CHANGELOG.md

@@ -1,5 +1,41 @@
 ## Changelog
 
+### v0.44.0 — role-aware drive management: protected lockout + customer type-to-confirm wipe + drive-list restyle (2026-06-11)
+
+The controller half of the storage-authorization redesign. The drive UI is now driven by the agent's
+authoritative **role** (`system` | `backup` | `user-data`, from `GET /api/disks`): the appliance's own
+system storage and the backup safety-net are visibly protected with NO destructive controls; the
+customer manages their own data drives with informed consent instead of a support ticket.
+
+- **`agentapi` client** — `DiskInfo` gains `role` + capacity (`total_bytes`/`used_bytes`/
+  `used_fraction`); `FormatResult` gains `role`/`needs_confirmation`/`durable_id`. `FormatDisk` now
+  takes `confirmed` + `durableID` and returns a new `ErrNeedsConfirmation` (user-data, awaiting the
+  customer's confirmation) distinct from `ErrFormatRefused` (system/backup, operator signature).
+- **Role-aware overview** (`settings.html`, "Meghajtók (ügynök nézet)") — restyled from a raw
+  `<table>` to **cards** in the house style: prominent storage name, mono device/mount detail, badges
+  for class (gyors/lassú), data ("Adatot tartalmaz"), **role** (🔒 Rendszer / 🔒 Biztonsági mentés —
+  védett / Felhasználói adat) and registered state, plus a **capacity bar** (the monitoring page's
+  green→amber→red `system-bar`). Destructive controls (Leválasztás / Törlés) render **only** for
+  user-data drives mounted under `/mnt`. System/backup get the lock badge and no controls.
+- **Type-to-confirm + name-the-apps** — a modal that (1) lists, **by name**, the deployed apps whose
+  data lives on the drive (`GET /api/storage/impact` → `appsUsingPath`), and (2) requires the customer
+  to **type the mount name** before the destructive button enables. No reflex-clickable destructive
+  action. Applies to both eject and wipe.
+- **Customer wipe** (`POST /api/storage/wipe`) — eject (unmount + deregister) then a server-side
+  two-step customer-confirmed format (learn the agent's durable id, then re-submit `confirmed:true`
+  bound to it). The mount name is re-checked server-side. A system/backup device is refused by the
+  agent regardless of what the controller sends.
+- **Init wizard** (`storage_init.html`) — the data-bearing path now uses the **customer-confirmation**
+  flow (type-to-confirm → re-submit confirmed) instead of the `felhom-opsign` instruction; the disk
+  selector is restyled to cards and lists only user-data targets. `storage_attach.html` likewise
+  restyled (cards, user-data only). No raw `<table>` remains in the storage UI.
+- **Tests** — `agentapi`: blank → ok, system/backup → ErrFormatRefused (+pending op), user-data → 
+  ErrNeedsConfirmation (+durable id), confirmed → formatted. `web`: init surfaces NeedsConfirmation and
+  does NO mount/register; confirmed init forwards the confirmation+durable id and proceeds; the
+  dependency-impact (`appsUsingPathIn`) names the right deployed apps.
+
+Pairs with **felhom-agent v0.23.0** (the authoritative role classifier + the tiered wipe gate).
+
 ### v0.43.0 — rebuilt storage management (guided init/attach/eject on the agent disk model) (2026-06-11)
 
 After the 8C de-privileging, the storage UI's buttons pointed at deleted routes (`/settings/storage/init`,