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

@@ -10,11 +10,11 @@
 # the mesh confirms the paths exist and mounts them, but creates and chowns none of it.
 #
 #   MESH_LAB_HOST_BINARY=.../mesh-host   MESH_LAB_BUNDLE=.../examples/substrate-first-node.lock
-# The runtimes are built by scripts/build-module-runtime.sh (one per module); every server image must
-# be in the local daemon to be stocked. The media/app images are pulled by their pinned digests and
-# tagged :mesh so repositoryFor matches the module.json paths (postgres/redis/portainer/mssql reuse
-# their existing local tags). The test loads each committed module.json from mesh-catalog and rewrites
-# its image references to what this scenario's own registry serves by digest.
+# The runtimes are built by scripts/build-module-runtime.sh (one per module) and must be in the local
+# daemon, because nothing serves them and nothing can. Every media/app image is pulled from the
+# internet by the node itself, over its uplink, by the digest its module.json already pins. The test
+# loads each committed module.json from mesh-catalog and rewrites only OUR image references, to the
+# ID the machine holds each one under.
 scenario: whole-mesh-ace
 
 segments:
@@ -25,50 +25,52 @@ segments:
 machines:
   anchor:
     at: { segment: hosting, address: [192.0.2.10] }
+    egress: true
     inbound: allow
     memory: 4GiB
     cpus: 4
     disk: 20GiB
+    # The substrate only, so the control plane's image only. The runtimes belong on the node that
+    # runs the modules, and a 20GiB disk has no room for them anyway.
+    images: [mesh-control:development]
   # The whole ace service set — 24 modules, ~50 containers, several heavy (Plex, Home Assistant,
   # Letta ~1.8GiB, Baserow ~1.5GiB, the UniFi controller's JVM, mssql ~2GiB). Sized past novox.
   ace:
     at: { segment: hosting, address: [192.0.2.20] }
+    egress: true
     inbound: allow
     memory: 18GiB
     cpus: 8
     disk: 120GiB
+    # Every runtime. Not mesh-control: the control plane runs on the anchor.
+    images:
+      - mesh-runtime-postgres:development
+      - mesh-runtime-redis:development
+      - mesh-runtime-mssql:development
+      - mesh-runtime-portainer:development
+      - mesh-runtime-sonarr:development
+      - mesh-runtime-radarr:development
+      - mesh-runtime-lidarr:development
+      - mesh-runtime-plex:development
+      - mesh-runtime-bazarr:development
+      - mesh-runtime-nzbget:development
+      - mesh-runtime-qbittorrent:development
+      - mesh-runtime-jackett:development
+      - mesh-runtime-ombi:development
+      - mesh-runtime-tautulli:development
+      - mesh-runtime-bookshelf:development
+      - mesh-runtime-home-assistant:development
+      - mesh-runtime-mosquitto:development
+      - mesh-runtime-influxdb:development
+      - mesh-runtime-grafana:development
+      - mesh-runtime-baserow:development
+      - mesh-runtime-letta:development
+      - mesh-runtime-nodered:development
+      - mesh-runtime-searxng:development
+      - mesh-runtime-unifi:development
 
 images:
-  # The first-node substrate.
-  - postgres:17-alpine
-  - cloudamqp/lavinmq:latest
   - mesh-control:development
-  # The module server images. Reused local tags where the exact version does not matter for a boot
-  # (postgres/redis/portainer/mssql); pinned-digest :mesh tags for the media/app images.
-  - redis:7-alpine
-  - lscr.io/linuxserver/sonarr:mesh
-  - lscr.io/linuxserver/radarr:mesh
-  - lscr.io/linuxserver/lidarr:mesh
-  - lscr.io/linuxserver/bazarr:mesh
-  - lscr.io/linuxserver/nzbget:mesh
-  - lscr.io/linuxserver/qbittorrent:mesh
-  - lscr.io/linuxserver/jackett:mesh
-  - lscr.io/linuxserver/ombi:mesh
-  - lscr.io/linuxserver/tautulli:mesh
-  - lscr.io/linuxserver/unifi-controller:mesh
-  - plexinc/pms-docker:mesh
-  - ghcr.io/pennydreadful/bookshelf:mesh
-  - ghcr.io/home-assistant/home-assistant:mesh
-  - eclipse-mosquitto:mesh
-  - influxdb:mesh
-  - grafana/grafana:mesh
-  - baserow/baserow:mesh
-  - letta/letta:mesh
-  - nodered/node-red:mesh
-  - searxng/searxng:mesh
-  - valkey/valkey:mesh
-  - portainer/portainer-ce:latest
-  - mcr.microsoft.com/mssql/server:2022-latest
   # The per-module runtimes (built by scripts/build-module-runtime.sh).
   - mesh-runtime-postgres:development
   - mesh-runtime-redis:development