A build machine gets its own credential, scoped to build work

The builder was documented as holding its own broker credential and
nothing else, and nothing issued one — so in practice it used whatever it
was handed, which was the broker's administrative account. A program
documented as holding its own credential and given somebody else's is
worse than one with no story at all.

`builder issue <name>` creates an account that may read the build queue
and write to the mesh exchange. Not a node account: a build machine is
not a node, and a node's queue carries its declarations.

Two faults found by running it, both about the answer path:

- the reply queue was left for the broker to name, and the account was
  scoped to `amq.gen-*` — one broker's convention. The builder built,
  could not answer, and the connection closed. Reply queues are named
  here now, deterministically.
- the answer then went via the DEFAULT exchange, where permission is
  granted per exchange rather than per queue. A builder allowed to use it
  could publish into any node's queue, which is the privilege a build
  machine most obviously should not have. Answers go through the mesh
  exchange, which it already may use, and an asker binds its reply queue
  to the same key and filters by correlation.

Verified against a real broker: a builder cannot consume a node's queue
and cannot publish to the default exchange. That check nearly reported
the opposite — an unconfirmed publish is asynchronous, so the refusal
arrives as a channel close afterwards and a naive test sees success. With
publisher confirms it is immediate. A negative security assertion made
against an asynchronous call is not an assertion.

Redelivery was observed working while fixing this: builders that died
before answering left their work on the queue, and the next builder did
all of it.

Also: the queue and exchange names exist in both `broker` and `link`,
because `link` imports `broker`. A test in an external package keeps them
agreeing — a builder scoped to a queue nothing publishes to takes no work
and says nothing about why.

cmd/mesh-builder/main.go

@@ -184,24 +184,21 @@ func answer(ctx context.Context, channel *amqp.Channel, publisher builder.Publis
 		return
 	}
 
-	replyTo := delivery.ReplyTo
-	if replyTo == "" {
-		// Nobody is waiting. Still reported, to the exchange, so a control plane that records
-		// builds hears about it — a build whose outcome exists nowhere is one nobody can audit.
-		if err := channel.PublishWithContext(ctx, link.Exchange, link.KeyBuilt, false, false,
-			amqp.Publishing{ContentType: "application/json", Body: body}); err != nil {
-			fmt.Fprintf(os.Stderr, "cannot publish a build result: %v\n", err)
-		}
-		_ = delivery.Ack(false)
-		return
-	}
+	// Always through the exchange, whether or not somebody is waiting.
+	//
+	// **Never the default exchange.** Permission there is granted per exchange rather than per
+	// queue, so a builder allowed to use it could publish into any node's queue — the privilege a
+	// build machine most obviously should not have. An asker binds its own reply queue to this
+	// key and filters by correlation; a control plane that records builds is bound to it too, so
+	// a result nobody asked for is still kept rather than reported into the void.
 	publishCtx, cancel := context.WithTimeout(ctx, 30*time.Second)
 	defer cancel()
-	if err := channel.PublishWithContext(publishCtx, "", replyTo, false, false, amqp.Publishing{
-		ContentType:   "application/json",
-		CorrelationId: result.ID,
-		Body:          body,
-	}); err != nil {
+	if err := channel.PublishWithContext(publishCtx, link.Exchange, link.KeyBuilt, false, false,
+		amqp.Publishing{
+			ContentType:   "application/json",
+			CorrelationId: result.ID,
+			Body:          body,
+		}); err != nil {
 		fmt.Fprintf(os.Stderr, "cannot answer a build request: %v\n", err)
 	}
 	// Acknowledged only once the answer is away, so a builder that dies before answering leaves