feat(stovepipe): queue-scoped storage parity — factory contract, bound stores, queue-leading keys

[behinddwalls]

Summary

Why?

Stovepipe's storage kept the pre-factory shape after submitqueue's seam moved to per-queue resolution: a queue-blind singleton aggregate, bare-ID keys on request and build, and controllers that learn a message's queue only by loading the entity. This brings the domain to full parity with the submitqueue contract so both storage seams read, route, and isolate the same way.

What?

The stovepipe internal queue payloads (ProcessRequest, BuildRequest, BuildSignal, Record) gain an additive queue_name echoed by every publisher from the entity it holds; consumers resolve their bound store set from it and guard that it matches the loaded request's queue. The storage extension gains Config{QueueName} and a Factory; the aggregate is queue-bound with no global remainder — stovepipe has no cross-queue read paths, and QueueStore, whose row key is the queue name itself, binds naturally (reads outside the binding miss, writes are rejected). RequestURIStore drops its explicit queue parameters in favor of the binding. The request table moves to a (queue, id) primary key and build gains a queue column with a (queue, id) key, so runner-minted build IDs no longer need cross-queue uniqueness; request_uri and queue were already queue-keyed. The MySQL backend keeps one shared pool with For binding a queue over it, and the host wiring adapts it into the factory seam. The contract suite becomes factory-driven with cross-queue isolation cases for the URI mapping and queue rows.

Test Plan

✅ go test ./... ✅ stovepipe storage contract suite, service integration suite, and stovepipe e2e via bazel (local runs need --sandbox_writable_path=$HOME/.docker) ✅ make fmt ✅ make lint ✅ make check-tidy ✅ make check-gazelle. Schemas are pre-production: tables recreated, no data migration.