[mnoah1]

Why?

Persist one-shot repair submissions using the existing key-value storage model, with a durable first-repair selection per build.

Stacked on #893, which defines the repair contracts, and #894, which describes the workflow.

What?

• Implement queue-scoped MySQL FixStore with primary-key reads and optimistic, full-snapshot updates.
• Key the initial Fix by the detecting BuildID. Retain OpenIssue references on each repair; observations and recovery evidence remain owned by build analysis.
• Store repair attempts in one new fix table with initiating build ID, issue references, submission state, execution reference, and optional provider metadata.
• Cover submission snapshots, including rejection of stale results, in MySQL integration tests.

Apply the new fix table before deploying the store. Build and OpenIssue keep their existing schemas.

Test Plan

• Passed the Stovepipe unit tests and the real-MySQL storage integration suite, including submission snapshots, issue-opening references, and rejection of stale submission results.
• Built affected service, fixer, and mock targets.
• Passed repository lint, dependency, Gazelle, mock-generation, and documentation checks. Strict documentation builds and Mermaid parsing passed after restacking.

Revert Plan

Revert this commit and deploy the previous service version before removing the added table. Existing validation data is preserved.

Issue Links

None — this persistence layer implements the repair design being prepared for team review.