v0.303.0 (code): after a restart, a backup capture waits for the drive's bind (R-897)

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS

CHANGELOG.md

@@ -1,3 +1,16 @@
+## v0.303.0 — after a restart, a backup capture waits for the drive (R-897; `09` §3 decision 176) (2026-10-07)
+
+**MinAgent: 0.131.0** (unchanged — no agent route is read; the signal is the controller's own mount table).
+
+- **R-897:** after a host restart the agent binds each drive under `/mnt/felhom-drives` and may normalize it once more
+  (umount + mount) when the guest started after the first bind; a recovery-unit capture in that second failed
+  (`mkdir /mnt/felhom-drives/hdd_1/backups: permission denied`, demo-hp 2026-10-07) and the operator got a false backup
+  failure. Now, for 10 minutes after the controller starts (`backup.DriveWaitWindow`), a capture for an app on a drive
+  runs only once that drive is a LIVE mount in the controller's own namespace (`/proc/self/mountinfo`, the same signal
+  the startup app gate uses): the 5-minute refresh skips the app until then; a data run waits (polls every 5 s). After
+  the window it runs anyway and says so once at WARN. The agent's bind order is unchanged. `internal/backup/driveready.go`;
+  tests `TestDriveReady_*` (3; red-proved: without the call the capture ran while the drive was not bound).
+
 ## Unreleased (2026-10-07) — the shared rule file; no code change
 
 - `.claude/rules/unprompted-work.md`: rule 11 (every helper prompt carries the brief's fences in full, `09` §3 decision 160) and the §1 line „no hub image build or hub deploy in a session the operator does not attend" (decision 162). Identical in all five copies.