M4.4: an unreachable build VM blocks its projects until it's back (#137)

M4.3's block, with new triggers and a way out. A VM out of reach at the
check before a run, in a run (which ends there: the driver, a toolchain
step and a requested step), or while preparing the workspace blocks every
project on it; the item stays ready, waiting on no one. On the intake round
it is tried again every tuning.build_vm.retry_s (300), and once it answers
it must still answer settle_s (180) later; then the work a lost run left
there is parked (pushed), the VM unblocked, and that said once.

A changed host key, at the check or on a retry, blocks the VM too, until
the operator's `vm ready`, which trusts the new key: `trust new host key`
is retired, and the message says it's a key problem that may be an
impersonation. Questions are answered while a VM is blocked, without it.
Starting the agent with a VM down no longer fails.

The walk breaks the VM's SSH, now or partway through a run, and checks that
no model works on a VM that is down; loop.qnt models the VM going and
coming back (unblocked_only_when_up). Together they found: a lost run's
work set aside by the next item there; a question left behind a block; a
lost VM swallowed while the toolchain step checked or recorded it; and a
remark waiting to be answered that outlived its PR's merge. All fixed.

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

docs/Architecture.md

@@ -709,8 +709,12 @@ 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).
+can't be reached blocks the same way, whether the check before a run finds it
+or a run loses it (which ends that run there); it is tried again in the
+background, and work goes on by itself once it has answered for a while. A VM
+that answers with a new host key blocks until the operator's `vm ready`.
+Questions are still answered while a VM is blocked, without it. The operator
+recovers a VM for now; `nisse-ops` later (O5).
 
 ### D4. Git, branches and PRs