Adopt a third-party workload, and keep a mesh between runs

**The adoption.** Software nobody here wrote, taking its credentials the
way such software does — from its environment — and needing two
containers that reach each other by name. The first module that could
not have been declared this morning: it needs the network shape and it
needs a sealed value to reach a container's environment.

Its password is accepted rather than generated, which is the whole shape
of an adoption: a service that already exists keeps the credential it
already has. Asserted properly — a wrong password is refused by the same
database, so the passing case means something.

**The warm scenario.** A mesh kept between runs and returned to, which
turned twelve minutes of bootstrap into thirty seconds of restore. Off
unless asked for: a run that is meant to mean something raises from
nothing.

Its guard fired for real during this work, unprompted — a mesh-host
commit landed and it refused the stale base, naming both commits, rather
than passing tests against yesterday's binary. That is 04-ISSUES/005's
rule one level down.

Three things the guard learned the hard way and now handles: a snapshot
captures disk and not memory, so the host is restarted after a restore
and asserted to have come back; the stocked image digests are worked out
while raising and a restored instance never raises, so they are kept;
and comparing only the repositories this run can see clears the ones it
cannot, so both directions are compared.

The one real bug behind five failed attempts was in mesh-host and it
reported itself precisely: a network shape the language had and no host
implemented. Everything else was scaffolding of mine.

scenarios/two-nodes.yml

@@ -28,6 +28,10 @@ images:
   # 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