feat(orchestrator): dispatch builds per speculation path

[behinddwalls]

Summary

Why?

The build stage triggered one build per batch, on the batch's full dependency list. Speculation needs one build per path, on the subset of dependencies the path assumes will succeed — that subset is what lets a batch be verified before the batches ahead of it resolve.

What?

The dispatch controller now reads the head's path set and starts a build for every pending path, on that path's own base. It only starts builds — stopping them belongs to the poll loop (next commit) — and it never writes the path set, which stays the speculate run's single-writer state; what this stage knows is the build it started, recorded in per-build rows of its own.

The write order is Trigger → Build record → write-once link (entity.PathBuild) → signal; each write makes the previous one reachable, and the link is the idempotency point for redeliveries. A lost link race publishes both builds' signals and acks — the poll loop keeps the one the link names. On redeliveries only, every live linked path gets its signal re-published, closing the crash window between link and signal without forking duplicate poll chains past the queue's dedup horizon.

The build signal carries only the runner's build ID and partitions on it, so one slow build cannot block a head's other paths. Known gap: a crash between Trigger and the link orphans that build; the fix is an idempotency key on BuildRunner.Trigger, marked TODO.

Also adds submitqueue/core/publish — the registry-lookup-and-send plumbing and the message-ID deduplication rule in one place.

Test Plan

✅ bazel test //submitqueue/orchestrator/controller/build/... //submitqueue/core/publish/... — write order, the base holding only assumed-success dependencies, redelivery republish without rebuild, lost-race double signal, halted batch starting nothing, redelivery healing for live linked paths, and a pin that no path-set write of any kind happens.

✅ make fmt, make gazelle, make mocks

Issues