Scenarios: egress where images are needed, and images: cut to what is ours

Every scenario that places a container runtime gives each of its machines
`egress: true` — a node that runs modules pulls images from the internet, which is what
a node does. The underlay-only scenarios (bootstrap-single, behind-nat,
segmented-and-unforwardable, the-ordinary-shape, two-on-a-segment) stay sealed on
purpose: an extra NIC would change the very reachability they are asserting about.

`images:` keeps only the mesh's own — 55 third-party entries leave whole-mesh-full
alone, and the machine fetches them itself by the digest its module.json already pins.
The whole-mesh beds also say per machine which of ours they get: novox the substrate
control plane and its own fifteen runtimes, ace its twenty-four, the two workstations
one each. That is not a lab economy. An operator's workstation holds the images its own
modules need, and giving these two the union would put some thirty gigabytes onto a
thirty-gigabyte disk.

bootstrap-with-registry.yml is deleted. It existed only to demonstrate the lab's
registry, nothing referenced it, and there is nothing left for it to demonstrate.

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

scenarios/two-nodes.yml

@@ -15,6 +15,7 @@ segments:
 machines:
   anchor:
     at: { segment: hosting, address: [192.0.2.10] }
+    egress: true
     inbound: allow
     # The whole substrate, the registry, the builder, an adopted workload and the modules under
     # test all land here — eleven containers before the forge arrives. At the 1GiB default this
@@ -24,21 +25,12 @@ machines:
     cpus: 4
   laptop:
     at: { segment: hosting, address: [192.0.2.20] }
+    egress: true
     inbound: allow
     memory: 2GiB
 
 images:
-  - postgres:17-alpine
-  - cloudamqp/lavinmq:latest
   - mesh-control:development
-  # So a module can mirror one into a registry of the mesh's own. The scenario's registry serves
-  # what the mesh's registry is built from — the same chicken-and-egg the bootstrap has, resolved
-  # the same way.
-  - registry:2
-  # A real third-party workload, for adopting one the way the conversion will. Its database is
-  # the substrate's postgres image rather than its own: what is under test is the mesh delivering
-  # a module, not which postgres it delivers.
-  - ghcr.io/umami-software/umami:postgresql-latest
   # And the builder, because it is a module the mesh assigns rather than a program somebody
   # starts by hand — which is the only way its credential can be one the mesh delivered.
   - mesh-builder:development
@@ -47,17 +39,10 @@ images:
   - mesh-provision-postgres:development
   # And the proxy, which is what turns a route grant into traffic actually arriving.
   - mesh-route-proxy:development
-  # And the cache, with its provisioner — the third provision after a database and a bucket,
-  # and the first whose tenancy is a keyspace rather than a namespace something else enforces.
-  - redis:7-alpine
   - mesh-provision-redis:development
   # And the object store's provisioner, so the module describing it can be planned. Without it
   # that module still names an image nothing serves, and planning it is refused — correctly.
   - mesh-provision-objectstore:development
-  # And a forge, so one of the real module descriptions can be started rather than only planned.
-  # It is the first of them to run: it needs a database from another module, a credential it did
-  # not choose, and a connection string it could not have written itself.
-  - gitea/gitea:1.22
 
 place:
   all: [host, runtime]