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

nisse-dev/src/nisse_dev/loop/tools.py

@@ -78,6 +78,16 @@ TOOLCHAIN_STEP = _tool(
     reason="What the work needs, and why.",
 )
 
+REQUEST_REIMAGE = _tool(
+    "request_reimage",
+    "The build VM seems broken beyond the usual fixes (reinstalling "
+    "dependencies, a toolchain_step): ask for it to be reimaged from its "
+    "template rather than diagnosing it further. Anything not pushed on it is "
+    "lost. Ends your turn; the project waits until the operator says the VM "
+    "is ready, and it is set up again from the repository first.",
+    reason="What is broken, and what you tried.",
+)
+
 # A conversation's tools (L1, L5): it talks, and may propose work.
 REPLY = _tool(
     "reply",
@@ -122,6 +132,7 @@ WAITING = frozenset(
         "propose_work",
         "propose_project",
         "toolchain_ready",
+        "request_reimage",
     }
 )