Ask the machine what it did, before asking what it produced

The forge test pushed and then waited for a database login. When the
containers were never created at all, it reported "no login was created"
— true, and silent about why. Two hundred and thirty seconds spent
proving something downstream of the actual failure.

A push being accepted and an apply having worked are different facts,
and this test depends on the second. It now reads what the machine says
about itself, and whether a container exists, before it starts waiting —
and carries the host's own log into the failure either way.

The suite otherwise passed 24 of 25 on this run, which is the first time
the forge reached a clean attempt with nothing upstream blocking it.

test/integration/mesh.test.ts

@@ -1862,6 +1862,19 @@ test("the forge runs, on a database the mesh gave it", { skip, timeout: 900_000
   }
   await mesh("push anchor", 300_000);
 
+  // **What the machine says it did, before asking what it produced.** This test pushed and then
+  // waited for a database role, so when the containers were never created at all it reported "no
+  // login was created" — true, and silent about the reason. A push that was accepted and an apply
+  // that worked are different facts, and the second is the one this depends on.
+  const state = await mesh("status");
+  assert.doesNotMatch(state, /failed/i,
+    `the machine did not do what it was told:\n${state}\n\n` +
+      `${(await on("anchor", `tail -30 /var/log/mesh-host.log`)).out}`);
+  const running = (await on("anchor", `docker ps -a --format '{{.Names}} {{.Status}}'`)).out;
+  assert.match(running, /\bpostgres\b/,
+    `the database module was pushed and no container for it exists:\n${running}\n\n` +
+      `${(await on("anchor", `tail -30 /var/log/mesh-host.log`)).out}`);
+
   // The database first: until the provisioner has made the login, the forge has nothing to
   // connect to and its own start would prove only that it retries.
   const psql = async (q: string) =>