feat(orchestrator): carry the queue explicitly on every internal payload

[behinddwalls]

Summary

Why?

Consumers today learn a message's queue only by loading the referenced entity from storage, and entity IDs are opaque — nothing may parse a queue out of an ID prefix. For storage to become queue-scoped (resolved per queue like every other extension), every consumer must hold the queue before its first storage read, so the queue has to ride on the wire explicitly.

What?

The internal payload types (RequestID, BatchID, BuildID, CancelRequest) gain a queue field; the change is additive JSON, and payloads written before the field existed decode with an empty queue. Publishers stamp it from the entity they already hold: start, mergeconflictsignal, batch, speculate, mergesignal, build, buildsignal, and the orchestrator cancel controller; the gateway cancel controller stamps the authoritative queue from the stored request summary, overriding caller input. Consumers guard that a non-empty payload queue matches the loaded entity's queue and reject mismatches as malformed (non-retryable, straight to DLQ) — the guard becomes the routing input once storage is queue-resolved. Buildsignal's re-publish to speculate now partitions by the batch's queue instead of the inherited batch-ID partition key, matching every other speculate publisher and restoring the per-queue serial-processing guarantee that stage relies on.

Test Plan

✅ go test ./... ✅ make fmt ✅ make lint — new unit tests cover the queue stamp on published payloads and the mismatch rejection guard.