feat(stovepipe): add BuildStore extension with MySQL implementation

[roychying]

Why?

The stovepipe build pipeline step needs a persistence layer for the Build entity added in #362. Following the immutable-entity + optimistic-locking storage pattern used elsewhere in the codebase (RequestStore, QueueStore), builds need their own store: build creates a row once (at Trigger), and buildsignal is the sole writer of Status/Version afterward. No reverse index from Request to its builds is needed since buildsignal and record always reach a build by the ID carried on their queue messages.

What?

• Adds the storage.BuildStore interface (stovepipe/extension/storage/build_store.go) with Create, Get, and a version-guarded Update (caller owns version arithmetic; the store performs a pure conditional write on oldVersion/newVersion).
• Adds the MySQL implementation (stovepipe/extension/storage/mysql/build_store.go) plus the build table schema (id, request_id, uri, base_uri, status, version), keyed by the runner-assigned build ID.
• Wires BuildStore into storage.Storage / mysqlStorage via a new GetBuildStore() accessor.
• Regenerates mocks for the new BuildStore interface (mockgen-generated, stovepipe/extension/storage/mock/).
• Adds a shared BuildStoreContractSuite (test/integration/stovepipe/extension/storage/suite.go) covering create/get, duplicate-create (ErrAlreadyExists), not-found (ErrNotFound), and CAS update (ErrVersionMismatch) semantics, and runs it against the MySQL backend (test/integration/.../mysql/storage_test.go).

Test Plan

• make test — unit tests pass
• make integration-test — attempted; currently blocked in this dev environment by a pre-existing, unrelated infra issue (local docker-compose is v1.29.2, which silently no-ops on the --wait flag our test harness passes, so no containers ever start). Confirmed this is environmental, not a regression from this change: all 8 Docker-based integration suites fail identically the same way, including ones untouched by this diff. The new TestMySQLBuildStore suite builds and its logic was verified by reading through the assertions against the BuildStoreContractSuite (create/get, duplicate-create, not-found, CAS update).

Issue