A build is announced under both names on the old bus, or merging breaks the live mesh

Found by asking what merging this would do to the mesh that is actually running — the
only place the question could have been asked, because the tests were green and both
buses were self-consistent.

Moving the build outcome to the role means a catalogue built from the current manifests
listens for the role's name. The catalogue *already running* listens for the module's,
because that is what it was told when it was installed. The two do not meet, so merging
as it stood would have stopped the live mesh's module graph being updated — silently,
since a binding that matches nothing is not an error.

A rename on a live bus needs the publisher and the subscriber to change together, and a
deployment cannot promise which arrives first. So the old bus announces under both names
and the order stops mattering. The module's own name retires with the bus, in step 5's
list; nothing has ever run on the bus being built, so there is no legacy name there and
this doubling has no counterpart.

internal/link/builds.go

@@ -27,6 +27,14 @@ const TheBuildMachine = "mesh-build-machine"
 func BuildWork() string    { return "mesh.seat." + TheBuildMachine + ".accept.build" }
 func BuildOutcome() string { return "mesh.seat." + TheBuildMachine + ".event.built" }
 
+// KeyRoleBuilt is the build outcome under the role's name, on the bus the mesh runs on today.
+//
+// The same event as KeyModuleBuilt and published beside it, because a catalogue installed before this
+// change listens for the module's name and one installed after listens for the role's. Both, until
+// this bus retires: a rename needs publisher and subscriber to change together, and a deployment
+// cannot promise which arrives first.
+const KeyRoleBuilt = "built"
+
 // Builders is how work reaches a build machine and how the outcome comes back.
 type Builders interface {
 	// Submit asks for one build and waits for its outcome.