Allow progressive insight, and apply two to the bus record

A record can assert a fact that goes stale while the decision it supports
stays right. Superseding for that buries a sound record under a second one
and makes every reader work out which is live. So a correction of fact is
now made in place, marked and dated, with the old wording quoted — bounded
by three conditions and checked by records.py, which fires on an unmarked,
undated or back-dated note. Judgements still supersede.

Applied to 0115: no conformance suite exists to recapture, and the full
genesis bed cannot run until the links exist. Designs 25 and 28 follow.

03-DESIGN/01-to-be/25-the-bus-on-nats.md

@@ -316,26 +316,20 @@ including the two places their dependencies put a bed later than the step that n
 real if the proofs divide with it. A step that cannot name what its bed proves is not a step, and is
 divided further before it is started.
 
-**Step 1 — the genesis bed**, a mesh raised on NATS from nothing:
-- a node enrols over TLS with a claimed token, and the enrolment user cannot read a declaration;
-- a push composes; the store is stopped; the push is held (nak with delay), the store returns, the
-  push applies, nothing was lost or duplicated;
-- a node that was away gets exactly the newest declaration, and a replayed older one is refused
-  by sequence;
-- an upgrade rolls out to two nodes;
-- a module's tool is invoked from another node and from a person's client, each with an account
-  that can invoke it, and refused from one that cannot;
-- a module's account cannot publish outside its `emits` nor subscribe outside its `consumes` —
-  refused by the server;
-- a module acks a delivery from its own durable consumer, and is refused acking another module's;
-- a user subscribes another module's or person's inbox prefix and is refused by the server, not
-  by the client's own good behaviour;
-- an event whose consumer keeps failing dead-letters after `max-deliver`;
-- an enrolment request held by a `nak`-with-delay cycle still reaches the enrolling node's inbox
-  once the controller answers — proving the reply travels in the payload and not the transport
-  field a consumer's ack has already claimed;
-- the `nats` container is not recreated when only its composed configuration file changes, and
-  a change to that file is live (a new user can connect, a revoked one cannot) within one
+**Step 1 — the genesis-broker bed**, a mesh raised from nothing, the server standing on it. The
+mesh does not yet *live* on this bus — nothing speaks it until step 3's implementations exist — so
+what this bed proves is the server, its configuration and the permissions, each of which the server
+itself enforces and a plain client can therefore check:
+- the four streams exist, asserted idempotently on a second start, with the retention of §3;
+- every account and permission in the composed file is derived from the manifests' `emits` and
+  `consumes` and nothing else, with each user's own ack subject and its own inbox prefix;
+- a user cannot publish outside its `emits` nor subscribe outside its `consumes` — refused by the
+  server, not by convention;
+- a user cannot ack another user's delivery, and cannot subscribe another's inbox prefix — refused
+  by the server, not by the client's own good behaviour;
+- the monitoring port is refused from anything but the private network;
+- the `nats` container is not recreated when only its composed configuration file changes, and a
+  change to that file is live (a new user can connect, a revoked one cannot) within one
   watcher-poll interval, without a restart.
 
 **Step 2 — the adoption bed**, a mesh already running that has never had this server:
@@ -358,14 +352,24 @@ divided further before it is started.
 - the shared library gained nothing but the binding: its surface is the protocol and the
   primitives, and a helper that arrived with the transport is a review failure, not a detail.
 
-**Step 4 — each converted flow against the behaviour it replaced:**
+**Step 4 — the mesh living on it.** The implementations exist from step 3, so this is where a mesh
+can first be raised on NATS and run:
+- a node enrols over TLS with a claimed token, and the enrolment user cannot read a declaration;
+- a push composes; the store is stopped; the push is held (nak with delay), the store returns, the
+  push applies, nothing was lost or duplicated;
+- a node that was away gets exactly the newest declaration, and a replayed older one is refused
+  by sequence;
+- an upgrade rolls out to two nodes;
+- an enrolment request held by a `nak`-with-delay cycle still reaches the enrolling node's inbox
+  once the controller answers — proving the reply travels in the payload and not the transport
+  field a consumer's ack has already claimed;
+- an event whose consumer keeps failing dead-letters after `max-deliver`;
+- a module's tool is invoked from another node and from a person's client, each with an account
+  that can invoke it, and refused from one that cannot;
 - a build source's change reaches the builder over the bus, and the build that follows is the one
   the change asked for;
 - an installation completes over the bus, with the same outcome the path it replaces produced;
-- a module's reports arrive, and a node that was unreachable catches up rather than losing them;
-- nothing of research 017's observation work is present — no heartbeat semantics, no condition
-  store — because that design is not written yet and a flow built ahead of it would have to be
-  rebuilt.
+- a node that was unreachable catches up on its reports rather than losing them.
 
 **Step 5 — the cutover bed:** a mesh on AMQP with a predecessor stand-in on the compatibility
 broker moves its bus in one rollout; every node reports on NATS afterwards; the stand-in's client