feat(review): scope the live auto-tune breaker to miner-originated PRs independently (#2352)

[JSONbored]

Summary

Closes #2352.

Extends the existing self-tightening precision circuit-breaker (src/review/auto-tune.ts) so a miner fleet's own self-review accuracy trips the SAME safety breaker independently of the maintainer's overall (mixed) review-stack accuracy, without ever blanket-penalizing human-submitted PRs to the same repo.

On the issue's own premise: #2352 asks to scope via computeGateEval's existing source filter, but that doesn't hold up -- source only ever distinguishes WHICH REVIEW ENGINE decided (currently always 'gittensory-native' in live use), not who authored the PR. I flagged this explicitly to the user before writing any code (a factually-incorrect issue premise requiring live D1 schema surgery on a table with a deliberate privacy design felt like it warranted confirmation, not a unilateral call) and got the go-ahead to build it correctly. The real signal -- confirmedContributor, an official-Gittensor-miner check via the live subnet API -- was already computed in processors.ts right where gate_decision rows get written, just never threaded through.

What changed

• migrations/0144: adds review_audit.miner_authored -- a coarse, non-identifying boolean CATEGORY (not a login), deliberately preserving review_audit's own design ("no actor-identifying data", since it feeds the anonymized cross-instance export -- see migration 0049's own comment). It reveals no more than "was this PR's author, at decision time, a confirmed official Gittensor miner."
• parity-wire.ts: recordNativeGateDecision takes an optional minerAuthored field, written alongside the existing (unchanged) source column.
• processors.ts: threads the already-in-scope confirmedContributor through at the one gate_decision write site (3 lines).
• parity.ts: computeGateEval gains an optional minerOnly filter, orthogonal to source (both AND together when both are set). Omitted -- every pre-maintainer: wire calibration accuracy into the live auto-tune circuit-breaker for miner-originated PRs #2352 caller -- is byte-identical to before.
• outcomes-wire.ts: runSelfTuneBreaker now runs a SECOND, miner-scoped computeGateEval pass alongside the existing one, then re-keys its rows with a :miner suffix before running them through the exact same applyAutoTune/applyCloseAutoTune/maybeAutoClear* primitives used for the existing pass. Every one of those (plus createFlagStore and listEngagedProjectScopes) is already fully generic over an opaque project string, so the distinct flag scope (holdonly:<project>:miner) falls out naturally with zero changes to auto-tune.ts itself -- it stays the "byte-faithful port" its own doc comment says it is. Refactored the existing engage+log+autoclear sequence into a shared runBreakerPassForReport helper, run once per scope, so the human/mixed pass's behavior is preserved byte-for-byte (identical event names, identical log shape) while the miner pass reuses the identical logic under a "miner_" event prefix.

Important nuance discovered while writing tests: the existing/unscoped pass is NOT disjoint from miner-authored data -- it has no miner_authored filter, so it counts every prediction for a project regardless of authorship. This preserves that pass's existing meaning (overall accuracy, unchanged, per the issue's own "preserve every existing invariant" deliverable) but means a project's miner-authored rows are counted in BOTH the mixed population and the miner-only subset. My regression tests account for this (see the doc comment at the top of the new test describe block in outcomes-wire.test.ts).

Validation

• npm run typecheck -- clean.
• npm run db:migrations:check -- 147 migrations OK, contiguous through 0144.
• npm run db:schema-drift:check -- clean (review_audit is a raw-SQL-only allowlisted table, not Drizzle-managed, so no schema.ts change needed).
• 122/122 tests pass across parity.test.ts + parity-wire.test.ts + outcomes-wire.test.ts; 308/308 across the broader affected suite (adds queue-lifecycle-guards.test.ts).
• Coverage measured on my actual diff, not just the whole file: parity.ts/parity-wire.ts's only gaps are in computeGateParity/computeParityReadiness (functions I never touched, already marked /* v8 ignore next */). outcomes-wire.ts has one pre-existing gap (the outer catch block) -- confirmed pre-existing, not introduced by this PR, by stashing my changes and re-measuring against origin/main's version: branch coverage was 89.42% both before and after (identical), proving my diff adds zero new gaps.

Test plan

Per the issue's own explicit deliverable:

• The miner-scoped breaker fires independently of the existing one, in BOTH directions (miner-only-bad-mixed-healthy, and mixed-bad-miner-healthy).
• The CLOSE-side mirror does too.
• Clearing one flag (via cooldown + precision recovery) never clears the other -- both merge- and close-side.
• recordNativeGateDecision correctly records miner_authored end-to-end through a real processJob webhook, for both a confirmed-miner author and a non-confirmed one.
• No miner-authored history at all -- fail-safe, byte-identical to before.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.13%. Comparing base (9ba03e0) to head (89fc97d).
⚠️ Report is 2 commits behind head on main.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5061   +/-   ##
=======================================
  Coverage   94.13%   94.13%           
=======================================
  Files         465      465           
  Lines       39542    39554   +12     
  Branches    14431    14433    +2     
=======================================
+ Hits        37223    37235   +12     
  Misses       1664     1664           
  Partials      655      655           

Flag	Coverage Δ
shard-1	46.50% <6.89%> (-0.01%)	⬇️
shard-2	33.56% <6.89%> (-0.01%)	⬇️
shard-3	31.33% <6.89%> (-0.01%)	⬇️
shard-4	32.69% <100.00%> (+0.02%)	⬆️
shard-5	33.43% <3.44%> (-0.01%)	⬇️
shard-6	44.94% <6.89%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/queue/processors.ts	95.42% <ø> (ø)
src/review/outcomes-wire.ts	89.79% <100.00%> (+0.74%)	⬆️
src/review/parity-wire.ts	96.42% <100.00%> (+0.13%)	⬆️
src/review/parity.ts	98.03% <100.00%> (+0.01%)	⬆️

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.