feat(storage): path-build link store for per-path builds

[behinddwalls]

Summary

Why?

Speculation needs one build per path, and something must record which build belongs to which path attempt. The runner chooses the build ID, so a caller holding a path cannot derive it; a keyed record is the key-value contract's mechanism for a reverse lookup.

What?

entity.PathBuild is new: the (pathID, attempt) -> buildID link, with storage.PathBuildStore, a MySQL implementation, schema, and mocks.

The record is write-once: created only once the runner has named the build, never updated. Absent means no build is recorded for the attempt; present names its build permanently, and a retried path is a new attempt under a different key. Because creation is the only write, the first insert also decides concurrent dispatches for the same attempt — ErrAlreadyExists tells the loser the attempt's build is someone else's. There is deliberately no reservation state and no version column: the stage that watches builds (later in this stack) stops any build whose path no longer wants it, so no reader needs to distinguish "idle" from "mid-dispatch".

entity.Build gains PathID and Attempt, and entity.SpeculationPath gains Base() — the dependencies the path assumes will succeed — so every consumer derives the base one way.

Test Plan

✅ bazel test //submitqueue/entity/... //submitqueue/extension/storage/...

✅ bazel test //test/integration/submitqueue/extension/storage/mysql:go_default_test — an attempt resolving to its build, ErrNotFound when undispatched, and a duplicate Create refused so the first link stands.

✅ make fmt, make gazelle, make mocks

Issues