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.