docs: v0.31.0 CHANGELOG + REPORT + CLAUDE banner (F9/F20-BUG2/BUG3 live-validated)

CHANGELOG.md

@@ -3,7 +3,35 @@
 All notable changes to **felhom-agent** are recorded here. Update on every code
 change that gets pushed.
 
-## v0.30.0 — AGENT-001: anti-retarget re-resolution for inline customer-confirmed wipe (2026-06-13)
+## v0.31.0 — live-drive F9 + F20-BUG2 + F20-BUG3 (disk bind/wipe) (2026-06-14)
+
+The last live-drive findings, all disk/`localapi`-side, implemented + deployed on `felhom-pve` and
+validated live on guest 9201 (approach: attach-to-existing, no re-provision — see the audit fixspec).
+
+- **F9 — guest data-drive bind survives a re-provision** (`4cd1d02`). The in-guest bind (`pct set -mpN`)
+  is config state a destroy+re-provision drops, and nothing restored it → a re-provisioned guest came up
+  with its enrolled HDD unattached. New `GuestBindStore` (durable-id-keyed, per guest, recorded at
+  guest-attach) + `ReassertGuestBinds` on agent startup re-adds any bind a guest is missing — only when
+  the durable-id still resolves to a present drive (a swapped/absent disk is never auto-bound), idempotent.
+  Plus `DiskInfo.GuestAttached` — the missing "bound into THIS guest" signal (vs mere host presence;
+  resolves the F2 `hdd_configured` disagreement). **Live-proven:** dropped the bind, restarted the agent
+  (real trigger) → re-attached with no manual call; reboot activated it; an HDD app then deployed onto
+  the drive with data on `/dev/sdb1`.
+- **F20-BUG2 — one wipe durable-id scheme** (`a2a76e7`). `/disks` advertised only `durable_id` (`uuid:`,
+  used for assign), but the wipe gate resolves `byid:`/`byuuid:` → confirming a wipe with the advertised
+  id was a `binding_mismatch`. New `DiskInfo.WipeDurableID` via a shared `s.deviceDurableID` seam used by
+  BOTH the list and the gate, so the id the customer copies is the id the gate accepts. **Live-proven:** a
+  confirmed wipe using `/api/disks`'s `wipe_durable_id` is accepted (no mismatch).
+- **F20-BUG3 — format runs detached; survives a request deadline AND an agent restart** (`4777f8a`). mkfs
+  ran under the HTTP request context, so a client deadline SIGKILLed it mid-write → corrupt disk. Now mkfs
+  runs off `s.baseCtx` via a persisted `formatJob` record; the handler still returns the synchronous
+  result (backward-compatible) but a dropped request no longer kills it. New `GET /disks/format/status`;
+  `RecoverFormatJob` on startup re-runs an interrupted durable-id-bound format (re-resolved; anti-retarget
+  — a blank/path-bound or unresolvable job is not auto-re-run). **Live-proven on the 916 GB felhom-usb:** a
+  2 s client timeout left a ~30 s mkfs running to a clean ext4 (the live-drive corruption is gone); an
+  agent restart mid-format was recovered + completed to a clean fs.
+
+
 
 **Security fix (from the 2026-06-13 deep-sweep audit).** The inline customer-confirmed wipe in
 `internal/localapi/disks.go` `handleDiskFormat` inspected and gate-bound the device by its durable id