The bed bootstraps through the installer, not around it

ADR 0067's own acceptance check said the lab must raise its anchor by running the
program a bare machine runs. It did not: whole-mesh-full applied the substrate bundle
by hand and then looped enrolment over all four machines as one continuous operation.
That gets the order right by accident and models the wrong shape — and an install
procedure that exists only as a test fixture is exercised by whoever writes tests and
never by whoever installs, which is why every bootstrap fault this year was found late.

Two acts now, and the first gates the second.

  GENESIS is novox running mesh-bootstrap: the installer is built from source before
  the raise (make bootstrap, carrying the control-plane image built in the same run),
  placed beside the host binary, given the two manifests it reads, and run. The bed
  then asserts a WORKING MESH OF ONE — the control plane answers, the registry replies
  on /v2/, the container called mesh-control is running from a registry-pinned digest
  rather than an image id, the registry agrees it serves it, temp-mesh-control is gone,
  and the mesh has heard from its node. The image-id check is ADR 0067's "the pivot
  completed" verbatim: if it is still an id, nothing was published and this mesh can
  never roll out its own upgrades.

  JOINING is ace, shanks and g14: host binary, token, enrol, run. novox is NOT enrolled
  again — the installer already did it, and a second identity is one the mesh does not
  know.

If genesis stops, the bed prints which of the installer's ten steps it stopped at and
goes no further. A second machine joining a mesh that is not ready is a different
failure, and running it would bury this one underneath it.

The anchor is no longer handed mesh-control:development. Its absence is the point: the
installer carries that image inside itself, and handing it over as well would make the
load say "already held" and leave the carrying untested — the same class of fiction the
lab's own registry used to hide. A unit test asserts the scenario keeps it out.

The registry is reached at 127.0.0.1:5000, which is a finding rather than a shortcut: a
runtime refuses a plain-HTTP registry at any address but a loopback one, so the digest
the control-plane module is pinned to is one only the anchor can pull. Enough here,
because only the anchor runs a control plane. Written down in the bed.

Claude-Session: https://claude.ai/code/session_01LrgweAeERJYBg88c5cKDzF

scenarios/whole-mesh-full.yml

@@ -42,6 +42,15 @@
 # network on the container port, so the host side is free to move). Reported as a topology finding.
 #
 #   MESH_LAB_HOST_BINARY=.../mesh-host   MESH_LAB_BUNDLE=.../examples/substrate-first-node.lock
+#   MESH_LAB_BOOTSTRAP_BINARY=.../mesh-bootstrap   MESH_LAB_CATALOG=.../mesh-catalog/modules
+#
+# GENESIS AND JOINING ARE TWO DIFFERENT ACTS, and this bed distinguishes them. novox is brought
+# into existence by `mesh-bootstrap` — the same program a bare machine runs — and is afterwards a
+# working mesh of one, with a registry and a control plane that is an ordinary module pinned to an
+# image that registry serves. ace, shanks and g14 then JOIN it: host binary, token, enrol, run. No
+# bootstrap, no substrate, no registry. novox is never enrolled twice, because the installer
+# already did it.
+#
 # The images: are the UNION of the novox set (feat/novox-conversions @ 431310f: the slug + roundcube
 # fixes, so only-office/de-spiegel/amqp-email-forwarder now resolve) and the ace media/home set, and
 # every one of them must already be BUILT on the workstation — nothing can fetch them.
@@ -76,12 +85,18 @@ machines:
     memory: 24GiB
     cpus: 8
     disk: 130GiB
-    # The substrate's control plane, the proxy, and a runtime per module novox is assigned.
-    # step-ca, photos, invoicing, novox.be, only-office, de-spiegel, amqp-email-forwarder, registry,
-    # firewall and fail2ban are not here because they carry no runtime image of their own — what
-    # they run is third-party or is the node itself.
+    # The proxy, and a runtime per module novox is assigned. step-ca, photos, invoicing, novox.be,
+    # only-office, de-spiegel, amqp-email-forwarder, registry, firewall and fail2ban are not here
+    # because they carry no runtime image of their own — what they run is third-party or is the
+    # node itself.
+    #
+    # **mesh-control is NOT here, and its absence is the point** (novox/hq ADR 0067). The anchor is
+    # brought into existence by the installer, and the installer carries the control plane's image
+    # inside itself — that is the whole reason a machine that can reach no registry can still raise
+    # a mesh. Handing it over from the workstation as well would mean the bed never found out
+    # whether the installer really carries it: the load would say "already held" and the fiction
+    # would be invisible, which is exactly the class of thing the lab's own registry used to hide.
     images:
-      - mesh-control:development
       - mesh-route-proxy:development
       - mesh-runtime-postgres:development
       - mesh-runtime-redis:development
@@ -164,7 +179,6 @@ machines:
 # a machine holds it because it was handed it. Everything else the modules run comes from the
 # internet and is not named here at all.
 images:
-  - mesh-control:development
   # --- per-module runtimes (union) ---
   - mesh-runtime-postgres:development
   - mesh-runtime-redis:development