One bus: the AMQP transport is gone from the controller

The mesh runs on the seat's bus alone (novox/hq ADR 0131, design 28 task 5.5). The old
transport's consume loop, build request, tool ask, management API and account scoping are
deleted, and the bus switch with them; the controller connects to the broker seat and to
nothing else. The store-window tests keep their assertions on a bus-less fake, and the tests
that only made sense for the old transport's in-memory holding go with it.

internal/link/receive_nats.go

@@ -23,6 +23,10 @@ import (
 // it first could not take it, and a controller that restarts mid-window has nothing to lose.
 
 // natsInbound consumes what nodes and modules say over NATS.
+// Prefetch is how many controls the controller holds unacknowledged at once: the store window
+// (ADR 0083) is the server's, and this is what it may hand this process ahead of its acting.
+const Prefetch = 64
+
 type natsInbound struct {
 	js *broker.JetStream
 	// follows is the kinds asked for beyond what nodes say (Also). The events those are are the
@@ -222,14 +226,6 @@ func (m *natsControl) HeldFor() time.Duration {
 	return time.Since(first)
 }
 
-// About is nothing here, and that is the point.
-//
-// Setting a held message aside when a newer one about the same thing arrives is what a controller
-// holding deliveries in memory can do. A naked message belongs to the server and comes back
-// whatever happened meanwhile, so the question "is this the past?" is answered by what the message
-// says instead — the digest of the declaration a report is about (window.go, design 25 §3).
-func (m *natsControl) About(string) {}
-
 // Answer publishes to the reply subject the request carries **in its payload**.
 //
 // Not `Respond`, and not the message's reply field: a message a JetStream consumer delivers has had