Hold a joining build for a person without superseding its delivery, join only on an engine that keeps own groups, and keep a held module's settings (hq ADR 0328 §8, ADR 0334; re-review of 96e15f86)

A delivery does not send a joining build held for its library or its engine: the module waits for a person,
the plan stays open saying so and judges its other modules, and sends it once nothing holds it. A held move is
no move for the gate. A module joins only on an engine at contract 7, and a held module is composed with the
settings it last ran with. The runner's verdicts are said for their modules and judged by whether a move
changes them. mesh-host pinned at #97 (7a41e120), its bundle now examples/foundation-first-node.lock.

testdata/beside/CAPTURED

@@ -8,7 +8,7 @@ private addresses. That is acceptable while mesh-controller is private; if it ev
 a second place to clean besides the catalogue itself.
 
 mesh-catalog  b9de001833b1b61b297182b8e3bcdae1cbdeace9  modules/*/module.json, modules/nats/Dockerfile
-mesh-host     d8e785bb4b4bbd4ad99dccec60c588032cd78fa6  examples/foundation-first-node-nats.lock
+mesh-host     7a41e120635b3f7b6cb94cca8b3fc4093e4e6110  examples/foundation-first-node.lock
 mesh-sdk      33917f91ac3cc213b879b32f3c70e2aa70395f98  conformance/events/module-event.json
 
 To move them, from this repository's root, with the two repositories checked out beside it:
@@ -18,7 +18,7 @@ To move them, from this repository's root, with the two repositories checked out
   git -C ../mesh-catalog archive <commit> modules | tar -x -C testdata/beside/mesh-catalog --wildcards \
     'modules/*/module.json' 'modules/nats/Dockerfile'
   find testdata/beside -name module.json -exec mv {} {}.captured \;
-  git -C ../mesh-host archive <commit> examples/foundation-first-node-nats.lock | tar -x -C testdata/beside/mesh-host
+  git -C ../mesh-host archive <commit> examples/foundation-first-node.lock | tar -x -C testdata/beside/mesh-host
 
 and write the commits here. The SDK is captured at the commit go.mod pins for git.novox.be/novox/mesh-sdk/go
 (the last part of its pseudo-version; novox/hq issue 449), which internal/link's conformance test holds it to:

testdata/beside/mesh-host/examples/foundation-first-node.lock

@@ -1,11 +1,17 @@
-// foundation-first-node-nats.lock — what a machine must be before a mesh exists, on the bus being
-// built (novox/hq ADR 0106, design 25).
+// foundation-first-node.lock — what a machine must be before a mesh exists: the one genesis bundle
+// (novox/hq ADR 0331 §2), on the bus the mesh runs on (ADR 0106, ADR 0131, design 25).
 //
-// The same twelve steps as foundation-first-node.lock, with one difference that matters: **the mesh
-// writes its own user list, and at genesis there is no mesh yet to write it.** So this carries the
-// first one — the controller's own account, at a well-known bootstrap password, exactly as the store
-// is reached at `postgres:bootstrap` and the old bus at `guest:guest`. It is rotated with those, and
-// from the controller's first composition onward the file is the controller's to write.
+// The whole bootstrap (novox/hq 03-DESIGN/01-to-be/07-the-foundation.md): a container runtime, a
+// filter, a store, a database per context, those contexts' schemas, the bus with its certificate
+// and its first user list, and the control plane running on top of them.
+//
+// **The mesh writes its own user list, and at genesis there is no mesh yet to write it.** So this
+// carries the first one — the controller's own account — and the control plane's address names the
+// same account. Both say `bootstrap`, and both are placeholders: the installer makes the account's
+// password, puts it in the address and its hash in the list (mesh-host internal/bootstrap
+// rootsecrets.go), and refuses a bundle whose bus connection it does not recognise. Until the first
+// node has enrolled the installer places the list the controller composes; from the bus's adoption
+// as the `nats` module on, the module receives it like any module (ADR 0331 §1, §5).
 //
 // The accounts file is its own file beside the server's configuration, because the server's own
 // settings belong to whoever raises it and the users belong to the mesh (design 25 §4). Both live in
@@ -15,7 +21,18 @@
 //
 // No `verify` on the TLS block, deliberately — that setting makes the server demand a *client*
 // certificate, and nothing in the mesh presents one: a host pins this server's exact certificate and
-// authenticates with a password (ADR 0004, design 25 §4).
+// authenticates with a password (ADR 0004, design 25 §4). The control plane pins it too, through
+// MESH_BROKER_CERTIFICATE, and dials the bus on the machine's own loopback.
+//
+// PINNED BY DIGEST, and the digest is not decoration: a tag can be made to point at a different
+// image, and this file is applied on a machine with no mesh to ask about anything (ADR 0006). The
+// registry prefix is the lab's; the digests are upstream's.
+//
+// The store's data is a NAMED VOLUME, not a directory on the machine. A directory the host
+// creates is owned by root, and the database runs as somebody else inside the container — so it
+// could not write, and the container crash-looped. A named volume lets the image set up its own
+// ownership, and outlives the container, which is what you want for the thing holding the mesh's
+// state.
 
 {
   "declaration": 1,

testdata/store-tests

@@ -47,3 +47,7 @@
 ./cmd/mesh-controller TestALibraryIsTakenOnlyWhenTheEngineSaysTheActIsDone
 ./internal/inventory TestTheSubPathsOfModulesPulledInByARequirementAreKept
 ./internal/inventory TestALibraryIsTakenWhenTheActIsDone
+./cmd/mesh-controller TestADeliveryWaitsForALibraryAndJudgesTheRest
+./cmd/mesh-controller TestAJoiningModuleIsHeldOnAnEngineOlderThanOwnGroups
+./cmd/mesh-controller TestAHeldModuleKeepsTheSettingsItRanWith
+./cmd/mesh-controller TestARunnersVerdictIsSaidAndJudgedByWhetherTheMoveChangesIt