The mesh composes the accounts; the module owns its server

The delivery question, decided. The alternative was a manifest field enumerating
the server's ports, TLS paths and store directory so the controller could write a
whole configuration file. That is wrong: those are properties of the container the
module raises, they live in its image and its mounts, and the controller would
have to be kept in step with a Dockerfile it never sees. So the mesh writes only
what only the mesh knows — who may connect — and the module's own configuration
includes it.

`ComposeAccounts` is that file. A test says what must *not* be in it as plainly as
what must: no port, no tls block, no store_dir. Each of those in the mesh's file
is a value the controller would then own, and the module could no longer change
its own image without the mesh agreeing.

`bus-users` is where a module wants it written, and **asking is not enough to
receive it**: the file holds every user's password hash, so a module that could ask
for it could read every credential on the bus. The claim on `mesh-broker`
authorises it, checked from the manifest alone. A holder with nothing composed is
refused rather than given an empty file, for the reason a certificate is — a bus
with no user list refuses every connection in the mesh and looks like a machine
problem.

Six claims checked against a running server before any of this was committed to,
and two of them changed what got written:

**An absolute include path is resolved relative to the including file's
directory.** `include /etc/nats/accounts.conf` from /etc/nats-server/nats.conf
makes the server look for /etc/nats-server/etc/nats/accounts.conf and refuse to
start. So both files share one directory, and the module declares its own as a
file resource beside the mesh's.

**`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, and so does a module's runtime. Every connection died at the TLS handshake
before any password was looked at, with an error — "client didn't provide a
certificate" — that reads as a fault in the client. Removed. TLS is still
required; verify only decides whether client certificates are checked.

The other four: a user in an included file authenticates, an unknown user is
refused so the include is the whole authority rather than an addition, a publish
outside a grant is refused, and rewriting the mesh's half alone makes a new user
appear — noticed by the module's own watcher, with no signal from outside, and
without dropping the connection the mesh already had. That last one is task 1.2's
payoff, collected.

internal/catalogue/manifest.go

@@ -423,6 +423,20 @@ type Manifest struct {
 	// A directory rather than one document for the same reason as above: each value is sealed
 	// separately and the mesh cannot open any of them to build a list.
 	Grants map[string]string `json:"grants,omitempty"`
+
+	// BusUsers is where this module wants the mesh's user list written, and it is only ever
+	// answered for the module holding `mesh-broker`.
+	//
+	// **The mesh writes who may connect; the module owns everything else about its server**
+	// (novox/hq design 25 §4, task 1.7). Ports, TLS paths and a store directory live in this
+	// module's image and its mounts and change when it does, so the module's own configuration
+	// carries them and includes this file. A controller that wrote the whole configuration would
+	// have to be kept in step with a Dockerfile it never sees.
+	//
+	// **Asking for it is not enough to receive it.** This file holds every user's password hash, so
+	// a module that could ask for it could read every credential on the bus — and the claim on
+	// `mesh-broker` is what authorises it, checked from this manifest alone.
+	BusUsers string `json:"bus-users,omitempty"`
 }
 
 // Build says how to produce this module's artifacts from its source.
@@ -641,7 +655,22 @@ type Certificate struct {
 
 // CertificateID and AuthorityID are the resource identities of what the mesh issued.
 func CertificateID() string { return "certificate" }
-func AuthorityID() string   { return "certificate-authority" }
+
+// ClaimsSeat says whether this manifest claims one named seat.
+func (m Manifest) ClaimsSeat(seat string) bool {
+	for _, c := range m.Claims {
+		if c.Name == seat {
+			return true
+		}
+	}
+	return false
+}
+
+// BusUsersID names the mesh's composed user list, so it is the same resource across every
+// declaration and a change to it is an update rather than a second file beside the old one — which
+// on a bus reading a directory would be two account lists, and the server would take both.
+func BusUsersID() string  { return "bus-users" }
+func AuthorityID() string { return "certificate-authority" }
 
 // FilteringID names the computed rule set, so it is the same resource across every declaration
 // and a change to it is an update rather than an addition beside the old one.