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/whole-mesh-novox.yml

@@ -1,10 +1,10 @@
 # The whole `novox` server's converted service set, installed together on ONE node behind the mesh
-# substrate — the whole-catalogue install the rebuild has never actually run. First stage of a
+# foundation — the whole-catalogue install the rebuild has never actually run. First stage of a
 # whole-mesh rehearsal (novox/hq).
 #
-# Topology, proven by test/integration/assigned-two-node-db.test.ts: the substrate (store, broker,
+# Topology, proven by test/integration/assigned-two-node-db.test.ts: the foundation (store, broker,
 # control) rides `anchor` and NOTHING else; ALL of novox's services ride the `novox` node — its own
-# postgres provider owns 5432 there, so it cannot co-locate with the substrate store on 5432. Both
+# postgres provider owns 5432 there, so it cannot co-locate with the foundation store on 5432. Both
 # machines sit on one public segment and enrol into the one mesh; an overlay is placed so a
 # consumer's binding `at` resolves to novox's private address and every consumer reaches the
 # providers co-located with it.
@@ -15,7 +15,7 @@
 #   apps        portainer verdaccio registry route-proxy mailu
 #   node-level  firewall fail2ban
 #
-#   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
 # The runtimes are built by scripts/build-module-runtime.sh (one per module that has code) and the
 # route-proxy image by scripts/build-route-proxy-image.sh; those must be in the local daemon,
 # because nothing serves them and nothing can. Every third-party image is pulled from the internet
@@ -29,7 +29,7 @@ segments:
     cidr: [192.0.2.0/24]
 
 machines:
-  # The substrate ONLY: store, broker, control. Nothing else lands here.
+  # The foundation ONLY: store, broker, control. Nothing else lands here.
   anchor:
     at: { segment: hosting, address: [192.0.2.10] }
     egress: true
@@ -37,9 +37,9 @@ machines:
     memory: 4GiB
     cpus: 4
     disk: 20GiB
-    # The substrate only, so the control plane's image only. Handing this machine the whole set of
+    # The foundation only, so the control plane's image only. Handing this machine the whole set of
     # runtimes would fill a 20GiB disk with images nothing on it will ever start.
-    images: [mesh-control:development]
+    images: [mesh-controller:development]
   # The whole novox service set — ~38 containers (five providers with runtimes, six consumers with
   # runtimes, portainer/verdaccio/registry/route-proxy, the nine-container Mailu stack and its
   # runtime) plus two node-level modules. mssql alone wants ~2GiB; Mailu, Nextcloud and Keycloak are
@@ -55,7 +55,7 @@ machines:
     # layers and the runtimes. A hundred gigabytes holds the whole set without exhausting the disk
     # mid-apply.
     disk: 100GiB
-    # Every runtime, and the proxy. Not mesh-control: the control plane runs on the anchor.
+    # Every runtime, and the proxy. Not mesh-controller: the control plane runs on the anchor.
     images:
       - mesh-runtime-postgres:development
       - mesh-runtime-redis:development
@@ -73,7 +73,7 @@ machines:
       - mesh-route-proxy:development
 
 images:
-  - mesh-control:development
+  - mesh-controller:development
   # The per-module runtimes (built by scripts/build-module-runtime.sh). registry, route-proxy,
   # invoicing, firewall and fail2ban carry no mesh-runtime image; route-proxy ships its own.
   - mesh-runtime-postgres:development