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

specs/loop_scenarios.qnt

@@ -74,4 +74,15 @@ module loop_scenarios {
       .expect(s.issues.get(99).linked == 1)
       .then(linkRecord)
       .expect(one_item_per_issue and itm(s, 1).issue == 99)
+
+  // M4.3: a build VM the driver finds broken blocks its project; nothing is
+  // taken up on it until the operator says `vm ready`, then work goes on.
+  run aBrokenVmBlocksUntilReadyTest =
+    init
+      .then(assignIssue(1)).then(intake(1, "A", false))
+      .then(activate(1)).then(requestReimage)
+      .expect(s.vmBlocked.contains("A") and s.active == 0)
+      .then(vmReady("A", true))
+      .then(activate(1))
+      .expect(blocked_vm_runs_nothing and s.active == 1)
 }