[mnoah1]

Why?

The existing fixer flow stores one fix ID on a build issue. That cannot independently track several backends repairing the same issue opening, or retain backend metadata before a submission is accepted. Extending the fixer to multiple issues and backends needs durable state for each issue/backend pair.

What?

Add an IssueRepair record and queue-scoped store keyed by issue opening and executor ID, with a MySQL schema, generated mocks, and storage tests. Each row retains an accepted fix ID or terminal skip reason, executor-owned map[string]string metadata, and a version for conditional updates. Empty fix ID and skip reason mean the submission is pending.

This PR provides the storage foundation while preserving existing dispatch behavior. #1034 extends the fixer API, and #1033 uses these records to dispatch independently to each backend.

Test Plan

./tool/bazel test //stovepipe/extension/storage/mysql:go_default_test //service/stovepipe/server:go_default_test --test_output=errors exercises pending creation, metadata round trips, accepted/skipped updates, stale-version rejection, and existing service wiring. Local lint, module-tidy, and Gazelle checks also completed.

Revert Plan

Revert dependent dispatcher changes first, then revert this PR. The additive table can remain.

Issue Links

No issue was provided. Persistence foundation for #1034, #1033, and #1035.

Stack

1. @ feat(stovepipe): store fixer submissions per issue and backend #1032
2. feat(stovepipe): extend fixer API for batching and multiple backends #1034
3. feat(stovepipe): offer newly opened issues to every registered fixer #1033
4. feat(stovepipe): extend fixer DLQ recovery to every issue and backend #1035