feat(entity): speculation path and run entities

[behinddwalls]

Summary

Why?

Queue-scoped speculation (#413) needs a shared vocabulary before any of its moving parts can be built: the speculator extension, its generator/allocator collaborators, and the controller that drives them all have to agree on what a speculative path is, how one is identified, and what states it can be in. Landing that vocabulary on its own keeps the contract reviewable in isolation and gives the follow-up branches in the stack a stable base to build against.

What?

Adds the speculation domain model in submitqueue/entity/speculation.go.

The stored model:

• SpeculationPath — one guess at how a batch's dependencies resolve: a head batch plus one bet per dependency, in queue order. Every dependency appears exactly once, so a path is self-describing and can be read without consulting an external relaxed set or dependency list. ID() is a hex SHA-256 over the head and its ordered bets, so identical paths share an ID and any difference in head, dependency, or bet yields a different one.
• DependencyBet / DependencyBetType — how a path treats one dependency: included (bets it lands), excluded (bets it does not), or dropped (ignored by conflict relaxation, so its outcome never invalidates the path).
• SpeculationPathStatus — the lifecycle of a path's current build attempt: pending, building, passed, failed, cancelling, cancelled. IsTerminal() deliberately excludes cancelling, which is a non-terminal intent — a build being cancelled may still reach passed or failed first.
• SpeculationPathEntry — the stored record for a chosen path, keyed by the content hash. It carries no build reference and no score: an execution is identified by (ID, Attempt), and a score is only meaningful within a single run.
• SpeculationPathSet — one head's chosen paths under a single version, holding both live and recently finished entries so a re-run cannot collide with an old build.

The run vocabulary, transient and never stored:

• PathAction — build or cancel. There is deliberately no merge or fail action; a batch's verdict is a controller-owned fact, not a proposed one.
• Speculation — one proposed action on one path.
• CandidatePath — a path paired with the ranking score assigned within a single run.

The three stored types round-trip through ToBytes/FromBytes (JSON), so they are storage- and queue-ready without pulling in a storage dependency. Enums are string-valued with "" sentinels, per the entity convention in CLAUDE.md.

No storage and no wiring — these are purely the entities the speculation extension and controller build on in the rest of the stack.

Test Plan

✅ bazel test //submitqueue/entity/... — passes.

speculation_test.go adds table tests covering:

• ID() determinism, and its sensitivity to head, dependency, bet, and bet order.
• IsTerminal() across every status, including the cancelling exclusion.
• SpeculationPathEntry.ID deriving from Path.ID().
• JSON round-trips for all three stored types, plus invalid-JSON and empty-input handling on each FromBytes.

No behavioral surface yet: nothing constructs or reads these entities on this branch, so there is nothing to exercise beyond the unit tests.

Issues