A module may watch a role's events, and the catch-up turns out to be unnecessary

Moving the build outcome onto its role broke the one module that consumes it, and my own
agreement check passed anyway. The catalogue's subscription derived
`mesh.mod.mesh-build-machine.event.built` — a module namespace for a role's event, which no
such module owns — so it started, connected, and its graph stayed empty. The check compared
names, and the names agreed: the build machine does emit `built`. Only the subjects
disagreed, and a subscription that matches nothing is silence.

A consumed name is a module's event unless it names a role, and this package cannot tell by
looking — so whoever resolved the declaration says which, the way it already does for a seat
held or used. A module that watches a role gets the role's event subject and a consumer
filtered on it; watching grants subscribe and nothing else, because hearing what a role
announced is not taking part in it.

The check now compares the two halves that actually have to match — the subject a consumer
subscribes against the subject an emitter publishes — with a case pinning that it catches
this exact confusion. Comparing names was checking the easy half.

**And that answered the open question about catch-up: there is nothing to build.** The
mechanism exists because a queue on the old bus receives only what is published after it is
bound, so everything built before the catalogue existed was announced to nobody. A stream is
a log and a consumer is a position in it: a consumer created afterwards starts at the
beginning, so the builds are simply there. Asked of a real server, since the whole decision
rested on it — three builds published with nothing listening, then a consumer created, and
all three waiting for it.

internal/broker/derived.go

@@ -3,6 +3,7 @@ package broker
 import (
 	"fmt"
 	"sort"
+	"strings"
 )
 
 // Streams and consumers derived from what modules declare.
@@ -103,16 +104,22 @@ type DeclaredSeat struct {
 // from its name: a module with a consumer per event would need an ack permission per consumer,
 // and the permission list would stop being derivable from the declaration.
 func ConsumerFor(p Principal) (Consumer, bool) {
-	if p.Kind != KindModule || len(p.Consumes) == 0 {
+	// A module that reacts to anything — a module's events or a role's (novox/hq ADR 0121). Watching
+	// a role was missing here, so the one module that does it got no consumer at all: it started,
+	// connected, and its graph stayed empty with nothing anywhere reporting why.
+	if p.Kind != KindModule || (len(p.Consumes) == 0 && len(p.Watches) == 0) {
 		return Consumer{}, false
 	}
 	perms, err := PermissionsFor(p)
 	if err != nil {
 		return Consumer{}, false
 	}
+	// Events, wherever they live: a module's own namespace, and the namespace of any role it watches
+	// (novox/hq ADR 0121). Tool subjects and inboxes are subscribed directly and are not a consumer's
+	// business, which is why this is a filter and not the whole list.
 	var filters []string
 	for _, s := range perms.Subscribe {
-		if len(s) > 9 && s[:9] == "mesh.mod." {
+		if strings.Contains(s, ".event.") {
 			filters = append(filters, s)
 		}
 	}