Adopt the glossary's vocabulary in the mutable design docs

"control plane" -> controller and "substrate" -> foundation throughout
03-DESIGN, 00-META and the README, with 06-the-control-plane.md and
07-the-substrate.md renamed to 06-the-controller.md and 07-the-foundation.md.
The immutable 02-DECISIONS records keep their original wording (and links to
them are unchanged) — a term retired here may still appear there, which the
glossary explains how to read.

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

03-DESIGN/01-to-be/12-a-module-repository.md

@@ -85,10 +85,10 @@ the worst possible moment.
 
 ## The builder runs on a node
 
-**Not in the control plane, and this is the same boundary as everywhere else.** Building needs a
-container runtime and a working tree; what the control plane may send a machine is bounded by the
+**Not in the controller, and this is the same boundary as everywhere else.** Building needs a
+container runtime and a working tree; what the controller may send a machine is bounded by the
 declaration language ([ADR 0005](../../02-DECISIONS/0005-the-node-host.md)), and *run this build*
-is not in it. The alternative — the control plane holding a container socket — would make it the
+is not in it. The alternative — the controller holding a container socket — would make it the
 one component that can do anything on any machine, which is the property the whole design is
 arranged to avoid.
 
@@ -96,7 +96,7 @@ So the builder is a program a machine runs, given work over the broker like anyt
 its own credential and nothing more.
 
 **A build is work, not state**, and that is why it does not travel as a declaration. Everything
-else the control plane sends a node is *what you should be*, reconciled forever. A build happens
+else the controller sends a node is *what you should be*, reconciled forever. A build happens
 once and is finished; as a declaration it would either rebuild on every reconcile or carry "and I
 already did this" — state about an event rather than about a machine.
 
@@ -203,7 +203,7 @@ at something. A build that failed before it knew what it was building keeps the
 is what a person goes and looks at.
 
 Recording is idempotent on the correlation, because a result arrives twice — once as the answer to
-whoever asked and once on the exchange, where the control plane is also listening. Two rows would
+whoever asked and once on the exchange, where the controller is also listening. Two rows would
 show one build as two, and which is real is not answerable afterwards.
 
 That is what a builds view reads, and until it existed there was nothing to read: a result was
@@ -381,13 +381,13 @@ have a route and one does not:
 
 | What | Why it cannot come through the loop | How it arrives |
 |---|---|---|
-| The control plane | It is what installs modules. Nothing can install it before it runs. | **Carried inside the installer** and published once there is a registry ([ADR 0067](../../02-DECISIONS/0067-genesis-is-a-pivot.md)) |
+| The controller | It is what installs modules. Nothing can install it before it runs. | **Carried inside the installer** and published once there is a registry ([ADR 0067](../../02-DECISIONS/0067-genesis-is-a-pivot.md)) |
 | The registry | It *is* where artifacts are delivered from. A store cannot be delivered through itself. | **Pulled from the public internet** — its image is an ordinary public one, never built ([`04-ISSUES/029`](../../04-ISSUES/029-the-artifact-store-cannot-be-delivered-by-the-artifact-store/00-report.md)) |
 | The builder | It is what builds. Nothing builds it before it runs. | Built at genesis by the init builder ([ADR 0070](../../02-DECISIONS/0070-the-catalogue-owns-the-module-graph.md)) |
 | The catalogue | It owns the module graph, and nothing can be resolved or installed without it. | Built at genesis by the init builder ([ADR 0070](../../02-DECISIONS/0070-the-catalogue-owns-the-module-graph.md)) |
 
 **How they arrive is settled and not yet built.** The installer carries an init builder, which
-clones the source and builds the control plane, the catalogue and the builder before a mesh exists
+clones the source and builds the controller, the catalogue and the builder before a mesh exists
 to install anything. Two things about that are open and named in
 [ADR 0070](../../02-DECISIONS/0070-the-catalogue-owns-the-module-graph.md): where the init builder
 clones from, given the forge normally runs on the mesh it would be rebuilding, and what it
@@ -400,7 +400,7 @@ three. This section previously said the list was closed at three, which was writ
 catalogue had an owner and is corrected here rather than left to be reasoned from.
 
 **And the answer for all four is now one mechanism, not four special cases.** Genesis carries an
-*init builder* and builds the core modules on the machine — control plane, catalogue and builder —
+*init builder* and builds the core modules on the machine — controller, catalogue and builder —
 rather than carrying a finished image of any of them. So the question is no longer "how does this
 one get here first?" asked once per component; it is answered once, by the thing that is carried
 being a builder rather than a result.
@@ -422,7 +422,7 @@ the mesh's registry assigned, exactly like everything the builder produces. A re
 from a running mesh which of its images were carried, and that is the point: carrying is how the
 first copy arrives, not what it permanently is.
 
-*Checked by the thing already checked at genesis: after installing, the running control plane is
+*Checked by the thing already checked at genesis: after installing, the running controller is
 pinned to a digest the mesh's own registry assigned, and not to the id of the image the installer
 carried. The same check applies to the builder and to the registry, and it is the same check —
 an image id where a registry digest belongs means the pivot did not finish.*