Scenario lifecycle, and how two scenarios coexist

ADR 0032: a scenario is a closed address space. Every segment materialises
as its own isolated link belonging to one instance, so two scenarios raised
from the same declaration hold the same addresses and never meet. The
declaration keeps its literal addresses and they mean what they say —
allocating from a pool would have made them a fiction, so a scenario
reproducing a specific topology would stop reproducing it.

The constraint that follows shapes everything: the lab never reaches into a
scenario over IP. It talks to machines through the virtualisation layer's
own channel. If it reached them by address, the workstation would need a
route into each scenario, and two carrying the same prefix would give it
two routes to one destination — failing not with an error but by one
scenario's traffic arriving in another.

That also makes reachability an honest question. Can this machine reach
that one is asked from INSIDE, by executing on the first, rather than
probed from a workstation that is not on the network and whose opinion
would be a different question with a misleadingly similar answer.

The lifecycle itself: six verbs, of which raise and destroy are enough to
be useful and the rest are what make repetition cheap. Raising is
convergent rather than incremental, because a lab behaving differently
from the thing it tests teaches the wrong habit.

A failed raise leaves the wreckage standing. Tearing down on failure
destroys the only evidence, which is backwards — a scenario that failed to
raise is more interesting than one that succeeded.

Snapshots are whole-scenario. Per-machine would be cheaper and wrong: the
mesh keeps state spanning nodes, so restoring one machine while its peers
move on produces a mesh that has never existed, and faults found there
would be artefacts of the lab.

Closes the declaration's open question about running several scenarios at
once.

03-DESIGN/01-to-be/02-scenario-declaration.md

@@ -634,10 +634,6 @@ is the one real absence, and it is exactly the double-NAT case.
 - **Where `place:` gets its artifacts from.** Before the mesh is self-hosting these come from
   outside; afterwards from the mesh itself. The declaration should not have to care, which
   suggests a named source rather than a path.
-- **Multiple scenarios at once.** Each needs its own segments and addresses, and the shape above
-  writes addresses absolutely. Whether a scenario carries literal addresses or a template the
-  lab allocates from decides whether two can run side by side — and there are only three
-  documentation ranges to go round.
 - **Nested forwarding** — `published:` names one gateway, so a machine behind two cannot be
   published through both.
 - **An address changing in place**, as a DHCP lease expiring under a machine that has not moved.