feat(storage): queue-leading primary keys with row-level cross-queue isolation

[behinddwalls]

Summary

Why?

The factory contract made queue-scoped storage instances the only way in, but the schema still let a bound instance reach another queue's rows: request, batch, build, batch_dependent, and request_batch were keyed by bare IDs. Leading every queue-scoped table's primary key with queue makes the binding real at the row level and leaves every table shardable by queue — cheap now (pre-prod, tables recreated), expensive to retrofit later.

What?

request and batch move to (queue, id), build to (queue, id) with a new queue column, batch_dependent to (queue, batch_id), and request_batch to (queue, request_id, batch_id); change, queue_batch_state, and request_summary_by_queue were already queue-leading, and the global read-model tables stay queue-free. The bound MySQL stores now stamp their queue into every write and prefix every read with it, so a wrong-queue read misses (ErrNotFound / empty) instead of leaking. The build key change also removes a latent cross-queue uniqueness assumption on runner-minted build IDs — two queues sharing one CI pipeline may now mint the same identifier. The storage contract suite gains a queue-isolation test covering all five re-keyed stores, and the e2e harness resolves its white-box request reads per queue.

Test Plan

✅ go test ./... ✅ storage integration contract suite via bazel, including the new cross-queue isolation cases ✅ make fmt ✅ make lint ✅ make check-tidy ✅ make check-gazelle. Schemas are pre-production: tables are recreated, no data migration.