Design 25 §4: the server verifies no client certificate, and writes only accounts

Two corrections of fact, both found by building the module's image and connecting
to it as a host would.

The first composed configuration said `verify: true`, which makes the server
demand a *client* certificate — and nothing in the mesh presents one. A host pins
this server's exact certificate and authenticates with the password the mesh
minted, and so does a module's runtime. Every connection in the mesh would have
died at the TLS handshake before any password was looked at, with an error that
reads as a fault in the client. TLS is still required; verify only decides whether
client certificates are checked. Mutual TLS is a later question and would need
machinery the mesh does not have — a certificate per module per node.

And §4 read as though the controller wrote the whole file. It writes the user list
and nothing else: ports, TLS paths and a store directory belong to the container
the module raises. The two files share one directory of necessity, because an
absolute include path is resolved relative to the including file's own directory.

The decision stands in both cases — accounts are composed, not called for, and
passwords are minted and sealed. What changed is what the file says and who writes
which half.

03-DESIGN/01-to-be/28-building-the-bus.md

@@ -178,23 +178,38 @@ paper is wrong until there is a second mesh to find out.
 
       **Out, and what each needs.**
 
-      *Delivery.* Resolution already prepends `file` resources whose content comes from the
-      rendering — a certificate does exactly this, and refuses when a module asks for one and none
-      was issued. The composed configuration is the same shape, and the open question is what the
-      module *declares* in order to receive it, which is design 29's ground rather than this
-      document's: a field naming where it wants the file, or nothing at all because the module
-      holding `mesh-broker` is the one that gets it. The server's own values — ports, TLS paths,
-      store directory — are constants of the module's own resources today and would have to be read
-      from one place rather than two.
+      **Delivery is in, and it settled what a module declares.** The mesh writes the *accounts* and
+      the module owns its *server*. The alternative was a manifest field enumerating ports, TLS
+      paths and a store directory so the controller could write a whole configuration — wrong,
+      because those are properties of the container the module raises and the controller would have
+      to be kept in step with a Dockerfile it never sees. So a module declares its own configuration
+      as a file resource and `bus-users` names where the mesh's half goes beside it; **asking is not
+      enough to receive it**, because that file holds every user's password hash, so the claim on
+      `mesh-broker` is what authorises it.
 
-      *Minting, and it is transport-coupled.* A password is minted at enrolment and at assignment,
+      Two things a running server changed. **An absolute include path is resolved relative to the
+      including file's directory** — `include /etc/nats/accounts.conf` from another directory makes
+      the server look for it *under* that directory and refuse to start — so both files share one.
+      And **`verify: true` was refusing every connection in the mesh**: it makes the server demand a
+      *client* certificate, and nothing in the mesh presents one — a host pins this server's exact
+      certificate and authenticates with the password the mesh minted ([ADR 0004](../../02-DECISIONS/0004-a-node-and-how-it-joins.md),
+      design 25 §4). Every connection would have died at the TLS handshake before any password was
+      looked at, with an error that reads as a fault in the client. Removed; TLS is still required,
+      because the block is what requires it and `verify` only decides whether client certificates
+      are checked. **Design 25 §4 should say this**, and says nothing about it today.
+
+      Also collected here: task 1.2's payoff, end to end against the module's own image — the user
+      list rewritten, the module noticing and reloading the server itself with no signal from
+      outside, and the connection the mesh already had still working afterwards.
+
+      *Still out — minting, and it is transport-coupled.* A password is minted at enrolment and at assignment,
       and an enrolment reply carries exactly one. **A node on the old bus must not be handed a
       credential for the new one**, so which bus a node is joining has to be a fact the controller
       holds before it can mint for both — the same switch the host's `Transport` is, from the other
       end.
 
-      *Asserting on start.* The streams, the controller's consumers and every node's are defined
-      and idempotent; nothing calls them from a start path yet.
+      *Still out — asserting on start.* The streams, the controller's consumers and every node's
+      are defined and idempotent; nothing calls them from a start path yet.
 
       **People are not in the list**, deliberately: the account model is built and `operator issue`
       is not (4.4), so there is nobody to derive. Left empty rather than guessed at.