Issue 127 resolved; design 29 says what wildcards are and how the rule is checked

Every module named its events the way the old bus spelled a routing key, so on the
new bus every cross-module subscription pointed at a namespace nobody publishes to.
Nothing failed — the services started and none of them reacted. Converted, and the
rule now has checks at both scales: at registration for one manifest, and as a test
across the whole catalogue where a consumed event's emitter is present.

It was larger than the report said, in two directions nobody had looked. Forty-three
files of module code pass the event name at runtime, so the code mattered as much as
the manifests. And both clients had to learn the mapping — without that, converting
the modules would have broken the mesh that is actually running, which is the
opposite of what fixing this was for.

Design 29 gained three things it did not say: what a wildcard is (`*` for one name,
`**` for the rest, spelled the mesh's way and derived to each bus's own), that an
event about a role belongs on the seat and why that is not yet possible, and how the
rule is checked — because "a subscription that matches nothing is silence" is exactly
why nobody noticed thirty-seven manifests being wrong the same way.

4.2 and 4.3 are unblocked. The catch-up half of 4.5 is not: it is a decision, and it
narrowed rather than closed. It cannot be a reply to a module's inbox, because that
needs the blanket grant design 25 §4 refuses.

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

@@ -518,10 +518,11 @@ it, and the beds that need a mesh living on NATS can finally run.
       What none of them can stand in for is a mesh raising itself, which is what this bed is — so this
       is where the code stops and the lab starts
 - [ ] 4.2 a build source's change reaches the builder over the bus, and the build that follows is
-      the one the change asked for — **blocked by
-      [issue 127](../../04-ISSUES/127-a-module-event-derives-a-subject-nothing-publishes/00-report.md)**
+      the one the change asked for — **unblocked**:
+      [issue 127](../../04-ISSUES/127-a-module-event-derives-a-subject-nothing-publishes/00-report.md)
+      is resolved, so an emitter and a consumer of the same event now land on the same subject
 - [ ] 4.3 an installation completes over the bus, with the same outcome as the path it replaces —
-      **blocked by the same**
+      **unblocked, same**
 - [~] 4.4 a person's client — **the account is done**: a person is not a module and holds no
       seat, so their authority is a list of tools (or `*` for an administrator) and nothing else.
       Held to four properties, each a way of being wrong that would not announce itself: nothing
@@ -533,12 +534,22 @@ it, and the beds that need a mesh living on NATS can finally run.
       Still to build: the client program itself — the command line and the MCP surface over it.
       It needs nothing from the consume side, so it is not blocked by step 3.
 - [~] 4.5 reports and catch-up: a node that was unreachable catches up rather than losing them —
-      **the reports half is in and proved against a server** (3.4): held through the store's
-      absence by the server rather than by the controller, superseded ones settled by the digest
-      they carry. The catch-up half is where issue 127 bites hardest: the controller replays a
-      build announcement under its **own** name rather than the builder's, so a catalogue
-      filtering the builder's subject hears nothing. Whether the controller may sign an event as
-      another module is a design question, not a wiring one, and it is open in that issue.
+      **the reports half is in and proved against a server** (3.4): held through the store's absence
+      by the server rather than by the controller, superseded ones settled by the digest they carry.
+
+      **The catch-up half is a decision, and issue 127 narrowed it.** The controller answers a
+      catalogue's request by re-publishing builds under its *own* name, which nothing subscribing the
+      builder's subject hears, and for which it holds no grant. Publishing them under the builder's
+      subject would be the controller signing an event as another module, which the derived namespace
+      exists to prevent. And it cannot become a reply to the catalogue's inbox either: answering a
+      module's inbox needs `_INBOX.>`, the blanket grant design 25 §4 refuses — found while giving the
+      controller the one narrow inbox it does need, to answer enrolments.
+
+      So two options are left, and they differ in kind. A subject the controller may publish and a
+      catalogue may subscribe — the mesh's own event space, which does not exist yet. Or a durable
+      consumer that starts at the beginning of the stream, which removes the need to ask at all and
+      leans on retention instead: sound while the events are still there, and silent when they have
+      aged out, which is the failure the request was invented to avoid.
 
 **Done when.** Each converted flow is proved against the behaviour it replaced, and the full genesis
 bed is green. **Observation is not in this step** — heartbeats, conditions and key-value state are