fix(orchestrator): mint distinct message IDs for cancel re-publishes

[behinddwalls]

Summary

Why?

The cancel controller published its speculate hand-off with the bare batch ID as the message ID. The queue deduplicates on (topic, partition key, message ID) against every row it has not garbage-collected yet, consumed ones included, so a redelivery's re-publish for the same batch was a silent no-op — leaving a batch stuck Cancelling with nothing driving it to terminal. Same class of bug as b1f5795 in stovepipe.

What?

publishBatchID now goes through submitqueue/core/publish: publish.UniqueID mints a distinct message ID per publish (and documents the dedup rule once), and publish.Message owns the registry-lookup plumbing the controller previously hand-rolled. The batch-path test now asserts the payload still carries the batch ID while the message ID is distinct per publish, and the multi-batch tests assert on the payload's batch ID for the same reason.

Test Plan

✅ bazel test //submitqueue/orchestrator/controller/cancel/...

Stack

1. docs(rfc): explain best-first speculation generation #513
2. feat(speculation): generator contract and bestfirst impl #446
3. feat(speculation): allocator contract and sticky impl #450
4. feat(speculation): standard composed speculator #451
5. feat(storage): speculation path set store #501
6. feat(storage): path-build link store for per-path builds #502
7. feat(orchestrator): dispatch builds per speculation path #503
8. feat(orchestrator): poll builds and stop the ones nothing wants #504
9. @ fix(orchestrator): mint distinct message IDs for cancel re-publishes #505
10. feat(orchestrator): re-plan the queue from the Speculator each run #506
11. feat(orchestrator)!: finalize batches from their speculation paths #507
12. feat(orchestrator): compose per-queue speculators and turn speculation on #508