Rename mesh-control -> mesh-controller, substrate -> foundation

One name per thing, per the HQ glossary: the module/container/image/binary/repo
becomes mesh-controller, the seat the-controller, and the store+broker pair the
foundation (embedded base bundles, default template and example lock renamed with
their go:embed directives). No behaviour change — a pure vocabulary rename.

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

scenarios/lavinmq-bed.yml

@@ -1,28 +1,28 @@
-# Two machines: one is the substrate, the other carries a lavinmq PROVIDER and a consumer of it.
+# Two machines: one is the foundation, the other carries a lavinmq PROVIDER and a consumer of it.
 #
 # lavinmq is the mesh's own control-plane broker (mesh-broker), and it is ALSO offered as a
 # user-facing capability: a module that needs a message queue gets its OWN broker — a scoped vhost and
 # user on a lavinmq PROVIDER — not an account on the control broker. That makes lavinmq the sharp
-# two-node case, for the same reason two-node-db is: the substrate's broker publishes 5672 on the node
+# two-node case, for the same reason two-node-db is: the foundation's broker publishes 5672 on the node
 # it runs on, and a lavinmq provider must publish 5672 too for its consumers to reach it — so the two
 # cannot share a machine. The moment a real amqp provider must own a node's 5672, it collides with the
 # control broker already there, and the chain is blocked single-node.
 #
-# This is the split that unblocks it. `anchor` runs the substrate (store, broker, control) and NOTHING
+# This is the split that unblocks it. `anchor` runs the foundation (store, broker, control) and NOTHING
 # else. `laptop` runs the whole chain: the lavinmq PROVIDER and the amqp-ping CONSUMER that requires
 # it. Provider and consumer are co-located on laptop, so the grant never crosses a node boundary; only
-# enrolment crosses to anchor, over the underlay both machines share. And because the substrate broker
+# enrolment crosses to anchor, over the underlay both machines share. And because the foundation broker
 # is on the OTHER node, the provider owns laptop's 5672 uncontested.
 #
-# It needs a host binary and the substrate bundle:
+# It needs a host binary and the foundation bundle:
 #
-#   MESH_LAB_HOST_BINARY=.../mesh-host   MESH_LAB_BUNDLE=.../examples/substrate-first-node.lock
+#   MESH_LAB_HOST_BINARY=.../mesh-host   MESH_LAB_BUNDLE=.../examples/foundation-first-node.lock
 #
 # HELPER — stock the two runtimes into the local daemon before the run (some may already be there):
 #   scripts/build-module-runtime.sh lavinmq   /tmp/lavinmq.tar
 #   scripts/build-module-runtime.sh amqp-ping /tmp/amqp-ping.tar
 # The service image cloudamqp/lavinmq:latest must be in the local daemon too — it is already stocked as
-# the substrate's own broker image; each node pulls what it runs from the internet, over its own
+# the foundation's own broker image; each node pulls what it runs from the internet, over its own
 # uplink.
 scenario: lavinmq-bed
 
@@ -46,7 +46,7 @@ machines:
     cpus: 2
 
 images:
-  - mesh-control:development
+  - mesh-controller:development
   # The lavinmq provider's runtime (reused for its run-once bootstrap and its provisioner) and the
   # amqp-ping consumer's runtime, both built by scripts/build-module-runtime.sh into the local daemon
   # and loaded onto the machines, which hold them by their own image IDs.