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/Architecture.md

@@ -95,8 +95,9 @@ hard wall; the classifier is a filter, not a guarantee.
 ### P5. Reversibility first
 
 - Work happens on **branches**, never on what others depend on (D4).
-- Work starts from a **fresh, clean workspace** (D3): a broken environment is
-  replaced, not diagnosed.
+- Work starts from a **fresh, clean workspace** (D3). A broken environment is
+  fixed the usual ways, and replaced when that doesn't work: the agent may ask
+  for its build VM to be reimaged rather than diagnose it at length.
 - **What must survive lives on the agent host and is snapshotted** (X4), and
   snapshots are taken before risky changes where the platform allows. Tool VMs,
   build artifacts and caches are disposable and rebuilt rather than repaired (X1).
@@ -703,6 +704,14 @@ reported but not asked about. Changes meant to last go into the repository's fil
 through a toolchain step; recurring ones go into the template (X4). Installing on
 any other host is dangerous.
 
+**A broken build VM blocks its projects.** When the usual fixes don't help, the
+driver asks for the VM to be reimaged from its template. The harness pushes the
+work in progress first, then blocks the VM: nothing runs on any project on it,
+across restarts, until the operator says `vm ready` (which also trusts its new
+host key), and a reimaged VM is set up again by the toolchain step. A VM that
+can't be reached blocks the same way (#137). The operator recovers it for now;
+`nisse-ops` later (O5).
+
 ### D4. Git, branches and PRs
 
 - **The harness owns branches;** plans and models never create or switch them.

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