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

README.md

@@ -144,6 +144,18 @@ export MESH_LAB_BUNDLE=<mesh-host>/examples/substrate-first-node.lock
 export MESH_LAB_MODULES=<mesh-control>/examples/modules
 export MESH_LAB_BUILDER=<mesh-control>/build/mesh-builder   # build/, which is git-ignored
 
+# The installer. `suite` builds it with mesh-host's `make bootstrap`, which embeds a `docker save`
+# of the control-plane image — so it is built AFTER that image, in the same run, or it carries a
+# stale one sealed inside a binary where nothing would ever notice. The whole-mesh bed raises its
+# anchor by RUNNING this, rather than by applying a substrate bundle itself (novox/hq ADR 0067).
+export MESH_LAB_BOOTSTRAP_BINARY=<mesh-host>/mesh-bootstrap
+export MESH_LAB_CONTROL_IMAGE=mesh-control:development   # optional; what it carries
+
+# A checkout of the mesh's catalogue. The installer reads the registry's and the control plane's
+# manifests from a copy of it ON THE MACHINE, because at genesis there is no forge, no build
+# machine and — until the registry is up — nothing serving anything.
+export MESH_LAB_CATALOG=<mesh-catalog>/modules
+
 # Built with `go build -o <path> ./examples/<name>` in mesh-control.
 export MESH_LAB_PROVISIONER=<somewhere>/postgres-provisioner
 export MESH_LAB_OBJECTSTORE_PROVISIONER=<somewhere>/objectstore-provisioner