M4.3: a broken build VM blocks its projects until it's ready

The driver can request_reimage(reason) when its build VM is broken past the
usual fixes (before the go-ahead too: it asks, it doesn't act). The harness
parks the work in progress (pushed to Gitea), then blocks the VM in the state
store (schema 5, vm_blocks): no item on any project on it is taken up, across
restarts. The operator hears once at top level, with the command to clear it,
and each blocked item's thread gets a line. `vm ready <project>` lifts the
block and trusts the VM's new host key; a reimaged VM is set up again by the
toolchain step, and the item that found it goes first.

loop.qnt gains the block (blocked_vm_runs_nothing) and a scenario; it found
that a reimage lost work in progress, hence parking first. The walk requests
reimages and recovers them, reimaged or not. The unreachable case reuses the
block in #137. Architecture P5 is softer, and D3 describes the block.

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

docs/Development-Plan.md

@@ -415,6 +415,29 @@ files agree, with the repository as the record rather than a harness-kept one.
 - With it, D1's rule made structural: until the go-ahead the fast path refuses
   anything that isn't harmless, so needs go in the restatement.
 
+**M4.3** *(revised with the operator: a broken VM blocks its projects).*
+**Done** (this PR). Cleaning caches and reinstalling dependencies were already
+contained and reported as the actions they are, so what is left is a VM broken
+past the usual fixes (D3).
+- The driver can `request_reimage(reason)`, before the go-ahead too (it asks,
+  it doesn't act). Its prompt says to try the usual fixes first, then ask rather
+  than go on diagnosing.
+- The harness parks the work first (pushed to Gitea, as for a switch; a VM too
+  broken to push loses it, and the operator is told), then **blocks the build
+  VM**: a durable block per host, so every project on it waits and none of its
+  items is taken up, across restarts. Said once at top level with the projects
+  blocked and the command that clears it, and in each blocked item's thread.
+- The operator's `vm ready <project>` (no name needed when only one is blocked)
+  lifts the block and trusts the VM's new host key. A reimaged VM has no marker,
+  so the toolchain step sets it up again before work; one said ready without a
+  reimage goes straight on. The item that found it goes first.
+- `loop.qnt` gained the block (`blocked_vm_runs_nothing`); it found that work in
+  progress was lost on a reimage, hence parking first. The walk requests
+  reimages and recovers them, reimaged or not.
+- Next: an unreachable VM blocks through the same mechanism, unblocked by a slow
+  background retry once it is back (#137). Later, nisse-ops reimages a VM itself
+  (M6.2, M7.6); a changed address means editing `build_host` and restarting.
+
 ### Phase 5 — Memory
 
 **M5.1 The vault.** *Pre-approved.* The folder, per-agent mounts, control tools,
@@ -473,6 +496,7 @@ vision; one local model for every agent; several forges (#26); a room per projec
 | #69 inline review comments | M2.1 |
 | #70 watch stall | M2.1 |
 | #77 conversational agent | M2.3 (questions), M2.7 |
+| #137 block on an unreachable build VM | After M4.3, which built the block |
 
 ## 6. Implementation notes