feat(entity): speculation path and run entities

[behinddwalls]

Summary

Why?

Queue-scoped speculation (#413) needs a shared vocabulary before the extension, generator, allocator, and controller can be built against it. Landing it on its own keeps it reviewable and gives the rest of the stack a fixed base.

What?

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

Stored:

• SpeculationPath — a head batch plus one bet per dependency, in queue order. ID() hashes the head and its ordered bets, so identical paths share an ID.
• DependencyBet / DependencyBetType — included, excluded, or dropped (ignored by conflict relaxation).
• SpeculationPathStatus — pending, building, passed, failed, cancelling, cancelled. IsTerminal() excludes cancelling: a build being cancelled may still reach passed or failed.
• SpeculationPathEntry — keyed by the content hash. No build reference, no score: an execution is (ID, Attempt), and a score only means something within one run.
• SpeculationPathSet — one head's paths under a single version, live and recently finished.

Transient, never stored: PathAction (build or cancel only — a verdict is a controller fact, not a proposal), Speculation, CandidatePath.

The three stored types round-trip through ToBytes/FromBytes. Enums are string-valued with "" sentinels. No storage and no wiring.

Test Plan

✅ bazel test //submitqueue/entity/...

Table tests cover ID() determinism and its sensitivity to head, dependency, bet, and bet order; IsTerminal() across every status; and JSON round-trips plus invalid and empty input for each FromBytes.

Stack

1. @ feat(entity): speculation path and run entities #444
2. feat(speculation): speculator extension contract #445
3. feat(speculation): generator contract and bestfirst impl #446