A run rebuilds what it tests, and leaves a receipt saying what it covered

The danger is not that the suite breaks. It is that nobody notices it
stopped running (novox/hq 04-ISSUES/005). The harness this replaces had
not built for two and a half months and nothing said so — and this suite
needs a hypervisor, so it inherits exactly that: it runs when somebody
remembers, and remembering is not a mechanism.

So running, recording, and rebuilding are one act:

- the host binary, control-plane image and builder are rebuilt from
  source first. The last two both parse manifests; building one and not
  the other left a binary eleven hours old refusing a field the mesh had
  just renamed, found by a full run.
- a receipt lands in XDG state — outside git, because the question is
  whether *this machine* has run it, and a receipt in git would be a
  claim about everybody's machine made by whoever committed last.
- `last-run` judges it and exits non-zero when it no longer counts.

Three faults found by running the thing rather than reading it, each now
held by a test confirmed to fail without it:

- counted() passed every test while parsing nothing. The runner colours
  its summary even into a pipe; the fixtures were clean text that had
  been imagined rather than captured. A fixture that agrees with the
  mistake proves the mistake.
- a receipt for `suite test/lastrun.test.ts` was indistinguishable from
  one for the real thing — 005's own symptom, rebuilt inside its remedy.
  The receipt now records what ran.
- a tree with uncommitted work reported the bare commit, claiming
  coverage of code nobody can check out. Nothing else could tell: the
  hash is identical either way.

Proven on real machines: 22/22, against all three repositories.

test/integration/mesh.test.ts

@@ -1396,17 +1396,6 @@ test("a service is reached by a name under the machine it runs on", {
   await mesh("push");
   await new Promise((r) => setTimeout(r, 25_000));
 
-  // `on`, not `must`: `is-active` exits non-zero for a unit that failed, so `must` would throw
-  // before the assertion below — taking every diagnostic with it. That happened, and the run said
-  // only "failed".
-  for (const machine of ["anchor", "laptop"]) {
-    const state = await on(machine, `systemctl is-active dnsmasq.service`);
-    if (state.out.trim() === "active") continue;
-    assert.fail(`the resolver is not running on ${machine} (${state.out.trim()}):\n\n` +
-      `its config:\n${(await on(machine, `cat /etc/dnsmasq.conf`)).out}\n` +
-      `${await diagnose(machine)}`);
-  }
-
   // Everything this test could want to know, gathered in one place.
   //
   // Three times now a diagnostic has not run because the thing before it threw: `must` on a
@@ -1424,6 +1413,17 @@ test("a service is reached by a name under the machine it runs on", {
     `asked directly:\n${(await on(machine,
       `timeout 5 resolvectl query postgres.anchor.internal 2>&1 || echo "no answer"`)).out}`;
 
+  // `on`, not `must`: `is-active` exits non-zero for a unit that failed, so `must` would throw
+  // before the assertion below — taking every diagnostic with it. That happened, and the run said
+  // only "failed".
+  for (const machine of ["anchor", "laptop"]) {
+    const state = await on(machine, `systemctl is-active dnsmasq.service`);
+    if (state.out.trim() === "active") continue;
+    assert.fail(`the resolver is not running on ${machine} (${state.out.trim()}):\n\n` +
+      `its config:\n${(await on(machine, `cat /etc/dnsmasq.conf`)).out}\n` +
+      `${await diagnose(machine)}`);
+  }
+
   // Through the machine's own resolver, by the path an application actually takes: nsswitch, then
   // files, then DNS. `dig` would ask a server directly and prove less — the resolv.conf module is
   // half of what is being tested, and only this path goes through it.