selftune accuracy circuit-breaker doesn't respect a repo's review.selftune: false opt-out

[JSONbored]

Problem

src/review/outcomes-wire.ts:614-655 (runSelfTuneBreaker, dispatched from the same "selftune" job case in src/queue/job-dispatch.ts:324-337 right after runSelfTune) computes computeGateEval globally with no repo filtering, and can engage/clear holdonly:<project>/closehold:<project> for a repo that explicitly opted out via review.selftune: false in its .loopover.yml. That flag's own documentation says it "excludes this repo from the tuning pass even though it's otherwise agent-configured" — selfTuneRepos() (used by runSelfTune itself, in src/review/selftune-wire.ts) correctly honors the opt-out, but the accuracy circuit-breaker half of the same cron path does not.

Area

src/review/outcomes-wire.ts (runSelfTuneBreaker), src/review/selftune-wire.ts (selfTuneRepos), src/queue/job-dispatch.ts (the "selftune" job case).

Proposal

Thread the same per-repo review.selftune: false opt-out check into runSelfTuneBreaker's repo selection (or into computeGateEval's inputs), so a repo that explicitly excluded itself from tuning cannot have its gate mode forced into holdonly/closehold by the breaker either. Requires a maintainer judgment call on whether the accuracy-breaker's own safety rationale (catching real gate-precision regressions) should ever override a repo's explicit opt-out, or whether opt-out should be absolute — that's a real product decision, not a mechanical fix, which is why this is filed maintainer-only rather than as a contributor-open bug despite being a genuine, verified inconsistency.

Deliverables

• A decision on whether review.selftune: false should also suppress the accuracy circuit-breaker for that repo.
• If yes: runSelfTuneBreaker filtered the same way selfTuneRepos() already is, plus a regression test asserting an opted-out repo's gate mode is never touched by the breaker.
• If no (breaker safety overrides opt-out by design): the review.selftune: false documentation updated to clarify it only exempts the tuning pass itself, not the accuracy breaker, so the current behavior stops looking like an unintentional gap.

Resources

Found during the 2026-07-17 contributor-pipeline-gardening ORB hardening audit. src/review/outcomes-wire.ts:614-655, src/review/selftune-wire.ts, src/queue/job-dispatch.ts:324-337, .loopover.yml.example's review.selftune documentation.

Boundaries

This touches the gate's own merge/close authority (holdonly/closehold are forced-hold states that override the normal AI verdict) — per this repo's own gardening-skill framework, anything touching the gate's authority stays maintainer-only regardless of how mechanical the underlying fix looks, pending a maintainer-reviewed design decision on the opt-out-vs-safety-override question above.

[linear-code]

JSO-4673