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/Tuning-Guide.md

@@ -565,3 +565,25 @@ reply in its thread starts a new conversation linked to it.
 - **Too low:** a conversation you come back to after lunch has to be picked up
   again from its summary.
 - **Too high:** idle conversations pile up in `status` and in the queue.
+
+### `tuning.build_vm.retry_s` — default 300
+
+How often a build VM that can't be reached is tried again (architecture D3).
+While it's out of reach, every project on it is blocked; each try is one SSH
+connection that gives up after 15 seconds.
+
+- **Too low:** a VM that is down for long is tried constantly, and each try
+  holds up the agent's other duties for up to 15 seconds.
+- **Too high:** work waits longer than it needs to after the VM is back.
+- **Deciding:** about how long a reboot of the VM's host takes. A VM you know
+  is back can be cleared at once with `vm ready <project>`.
+
+### `tuning.build_vm.settle_s` — default 180
+
+Once an unreachable VM answers again, how long it must keep answering before
+work goes on: SSH comes up before a VM has finished booting.
+
+- **Too low:** work starts on a VM still running cloud-init or starting
+  services, and fails in confusing ways.
+- **Too high:** work waits after the VM is ready.
+- **Deciding:** how long the template takes from SSH answering to fully up.