[mnoah1]

Why?

Persist repairs so several failure episodes can share one fix and controllers can discover active work using the existing key-value storage model.

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.
• Persist Queue.ActiveFixIDs through the existing QueueStore and Queue.Version; preserve membership across other queue updates.
• Keep failure/recovery evidence and the authoritative FixID assignment in build-analysis episode records. Retain BreakageRef membership on each repair.
• Store repairs in one new fix table with episode references, lifecycle, execution ID, and optional provider metadata.
• Cover submission and retry snapshots, including rejection of stale results, in MySQL integration tests.

Existing databases need queue.active_fix_ids added and backfilled with an empty JSON array before deploying the new queue-store code. The schemas initialize fresh databases.

Test Plan

• Passed all 21 Stovepipe unit-test targets and the real-MySQL storage integration suite, including concurrent active-membership updates and preservation during queue enablement changes.
• 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 schema fields/table. Existing validation data is preserved.

Issue Links

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