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/raise_live_test.go

@@ -143,3 +143,54 @@ func TestRaisingAMeshRolesWorkQueue(t *testing.T) {
 		t.Fatalf("the holder got no worker on the role's queue: %v", err)
 	}
 }
+
+// **A consumer created after the fact still sees what came before it**, which is why the mesh needs no
+// catch-up at all on this bus (novox/hq 04-ISSUES/050).
+//
+// On the bus the mesh runs on today a queue receives only what is published after it is bound, so
+// everything built before the catalogue existed was announced to nobody — and on a fresh mesh that is
+// always the foundation, because those are the things the catalogue needed in order to exist. A whole
+// mechanism was built for it: the catalogue asks, the controller re-publishes.
+//
+// A stream is a log and a consumer is a position in it. A consumer created later starts at the
+// beginning by default, so the builds are simply there. Asked of a real server rather than assumed,
+// because the whole decision about whether to keep that mechanism rests on it.
+func TestAConsumerCreatedAfterwardsStillSeesWhatCameBefore(t *testing.T) {
+	js := aLiveBus(t)
+	if err := AssertMeshStreams(js); err != nil {
+		t.Fatal(err)
+	}
+	if err := js.Context().PurgeStream("EVENTS"); err != nil {
+		t.Fatal(err)
+	}
+
+	// Genesis: things are built before anything is listening.
+	built := []string{"base", "store", "mesh-catalog"}
+	for _, m := range built {
+		if _, err := js.Context().Publish("mesh.seat.mesh-build-machine.event.built",
+			[]byte(`{"module":"`+m+`"}`)); err != nil {
+			t.Fatal(err)
+		}
+	}
+
+	// Now the catalogue is installed and the controller creates its consumer.
+	c, ok := ConsumerFor(Principal{Kind: KindModule, Node: "one", Module: "mesh-catalog",
+		Watches: []Seat{{Name: "mesh-build-machine", Emits: []string{"built"}}}, PasswordHash: "x"})
+	if !ok {
+		t.Fatal("a module that watches a role got no consumer")
+	}
+	t.Cleanup(func() { _ = js.Context().DeleteConsumer(c.Stream, c.Name) })
+	if err := js.EnsureConsumer(c); err != nil {
+		t.Fatal(err)
+	}
+
+	info, err := js.Context().ConsumerInfo(c.Stream, c.Name)
+	if err != nil {
+		t.Fatal(err)
+	}
+	if info.NumPending != uint64(len(built)) {
+		t.Fatalf("a consumer created after %d builds has %d waiting for it — if this is 0 the mesh "+
+			"does need a catch-up after all, and the reasoning for deleting it is wrong",
+			len(built), info.NumPending)
+	}
+}