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/25-the-bus-on-nats.md

@@ -7,7 +7,7 @@ code:
   - mesh-tools src/broker-amqp.ts (to be replaced)
   - mesh-catalog modules/nats (to be written)
   - mesh-sdk src (the protocol's NATS binding, step 3)
-updated: 2026-09-26
+updated: 2026-09-27
 decisions:
   - 02-DECISIONS/0106-the-bus-is-nats.md
   - 02-DECISIONS/0119-amqp-is-a-provision-not-the-bus.md
@@ -213,7 +213,32 @@ expresses this exactly, per subject, and better than a vhost could:
 - **A person's user** (§7) is a module-shaped user with permissions on the tool subjects it may
   invoke, issued and revoked by the controller like any account.
 
-**Accounts are configuration, not API calls.** The controller composes the server's user list and
+**The server does not verify client certificates, and TLS is still required.** *Revision,
+2026-09-27, 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 ([ADR 0004](../../02-DECISIONS/0004-a-node-and-how-it-joins.md)),
+and a module's runtime does the same. With it on, every connection in the mesh dies at the TLS
+handshake before any password is looked at, and the error — "client didn't provide a certificate" —
+reads as a fault in the client rather than in the bus's configuration. The `tls` block is what makes
+TLS required; `verify` only decides whether client certificates are checked. What is given up is a
+second factor the mesh has no machinery to issue or rotate — a certificate per module per node — and
+what is kept is stronger than a name check in both directions: an exact pin outward, a password
+scoped per user inward. **Mutual TLS is a later question and would need that machinery first.**
+
+**The mesh composes the accounts; the module composes its server.** *Revision, 2026-09-27, while
+building the composition.* An earlier reading of the paragraph below had the controller writing the
+whole file. It writes only the user list. A server's ports, its TLS paths and its store directory
+are properties of the container the module raises — they live in its image and its mounts and change
+when it does — so the module declares its own configuration and `include`s the mesh's half. A
+controller that wrote the whole file would have to be kept in step with a Dockerfile it never sees,
+and a module could not change its own image without the mesh agreeing. Asking for the user list is
+not enough to receive it: the file holds every user's password hash, so the claim on `mesh-broker` is
+what authorises it. And the two files share one directory of necessity — an absolute include path is
+resolved relative to the including file's own directory, so a server given one from elsewhere looks
+for it underneath that directory and refuses to start.
+
+**Accounts are configuration, not API calls.** The controller composes the mesh's user list and its
 permissions into a file the host declares. **How that file reaches the running server is §5's,
 not this one's** — revision, first review: an earlier draft said "reloads" and cited a precedent
 that does not apply to a container (see §5). No management API, no credential travelling through a