The base image carries the network tools, and a scenario that grows

A sealed scenario cannot install wireguard-tools any more than it can install a
container runtime, so a lab without them cannot test connectivity at all --
which is most of what the mesh does between machines. Installed and not
started: what a node runs is the mesh's decision, and a lab that brought the
interface up itself would be testing its own setup.

growing-mesh exists to be grown. The point is not the third machine, it is that
adding one changes every other node's peer list -- so each has to be told
again, or the newcomer is on a network nobody else can see.

scenarios/growing-mesh.yml

@@ -0,0 +1,33 @@
+# Three machines, joined one at a time.
+#
+# The point is not the third machine. It is that adding one changes **every other node's** peer
+# list: each existing node has to be told again, or the newcomer is on a network nobody else can
+# see. A mesh that only configures the arriving node looks like it worked and is half a network.
+#
+# So this scenario exists to be raised, then grown — enrol two, push, check; enrol the third,
+# push, and check that the first two changed.
+scenario: growing-mesh
+
+segments:
+  hosting:
+    kind: public
+    cidr: [192.0.2.0/24]
+
+machines:
+  anchor:
+    at: { segment: hosting, address: [192.0.2.10] }
+    inbound: allow
+  laptop:
+    at: { segment: hosting, address: [192.0.2.20] }
+    inbound: allow
+  workstation:
+    at: { segment: hosting, address: [192.0.2.30] }
+    inbound: allow
+
+images:
+  - postgres:17-alpine
+  - cloudamqp/lavinmq:latest
+  - mesh-control:development
+
+place:
+  all: [host, runtime]