calibration: unify the tightening loop under the backtest evidence standard

[JSONbored]

Problem

Epic #8211 track D capstone. Loosening moves only on Pareto-floored backtests; the legacy TIGHTENING loop (src/review/auto-tune.ts, shadow-soak + precision-floor triggers) predates that standard. Two evidence regimes for opposite directions of the same knobs is incoherent and blocks the drift sentinel's tighter-alternative findings from ever acting.

Requirements

⚠️ Required pattern. Design-first inside the issue before code: map every auto-tune trigger onto the registry model (a tightening candidate ladder above shipped, same splits, same sample floors) and decide per trigger whether it becomes a registry evaluation or stays bespoke WITH WRITTEN REASON. Behavior-pinning tests must hold auto-tune's current outcomes byte-stable until each trigger's migration lands.

• Registry entries gain an optional tightening ladder; evaluateKnobLoosening generalizes (or gains a sibling) with direction-aware Pareto orientation — tightening trades recall for precision, so the floor's axes orientation must be explicit, not reused blind.
• Applies remain double-gated per direction (separate env flag for tighten-autonomy; default off).

Deliverables

• Design section committed to the docs page + the migration map in this issue
• First migrated trigger end-to-end with byte-stable-pinning tests for the rest

Links & Resources

#8211 (epic), the slop/quality registry issue (blocked-by, shares registry churn), src/review/auto-tune.ts, src/review/selftune-wire.ts

Boundaries

No trigger loses coverage mid-migration: old path keeps running for unmigrated triggers.

maintainer-only — gate-authority unification.

[linear-code]

JSO-5709

[JSONbored]

Design: migration map (required pattern — design before code)

The legacy tightening loop has four triggers across src/review/auto-tune.ts, src/review/selftune-wire.ts, and src/review/auto-apply.ts. Per-trigger disposition:

#	Trigger	Evidence regime today	Decision	Reason
T1	Merge-precision circuit breaker (planAutoTune → holdonly:<project>, cooldown auto-clear)	Forward-measured, reversal-weighted merge precision < 0.85 over ≥10 would-merges	Stays bespoke	It is a boolean capability breaker, not a threshold move: there is no candidate ladder to evaluate, and its evidence is realized-outcome-graded — the strongest regime we have. Re-basing it on a fired-signal backtest corpus would weaken its evidence, and a breaker must engage on the current window immediately rather than wait for corpus accumulation.
T2	Close-precision breaker (planCloseAutoTune → closehold:<project>)	Same, close side	Stays bespoke	Symmetric twin of T1; identical reasoning.
T3	Advisor tighten recommendation (mergePrecision < 0.90 → overridePayload.confidenceFloor = 0.95) + shadow-soak/promotion (runAutoApplyRecommendations)	Forward precision failure + time-boxed shadow soak	Migrates to the registry model — mechanism ships in this issue; T3's own cutover follows once its target tunable (qualityGateMinScore) can carry a registry entry	It IS a threshold move with a principled target — exactly the registry's shape. But its consumption tunable has no global shipped default (the #8224 finding), so declaring its knob today would mean inventing semantics. The direction-aware mechanism lands now; T3 stays byte-stable under behavior-pinning tests until its knob can be declared honestly.
T4	Advisor loosening branch (closeFalse > 0 → "loosen the scope rules" rec)	Unreachable by construction in loopover (evalRowFromCalibration holds the close side at 0)	Retired concept	Superseded by the registry loosening loop (#8121/#8159), the only loosening authority. The branch remains in the ported advisor for faithfulness and stays unreachable — pinned by the existing selftune tests.

First migrated trigger (end-to-end in this issue's PR)

The drift sentinel's (#8213) tighter-alternative findings become actionable through the registry — today they can only alert, which is the incoherence this capstone closes:

• Engine — explicit orientation, not blind reuse: compareTighteningBacktestScores(baseline, candidate, maxRecallSacrifice). Tightening trades recall for precision by design, so the Pareto floor is re-oriented: precision must strictly improve; recall may drop by at most the declared bounded sacrifice; any precision regression or over-bound recall loss is regressed. The loosening comparator is untouched.
• Registry: LoosenableKnob gains an optional tightening ladder — { candidates (ascending, above shipped), hardMaximum, maxRecallSacrifice, autotuneEnvVar, eventType }. The env var is separate from the loosening one and default OFF (per-direction double gating, as this issue requires). evaluateKnobTightening mirrors evaluateKnobLoosening verbatim: same split seed/fraction, same sample floors, smallest step first, hard bound no evidence may cross.
• Run path: runKnobTightening beside the generic loosening loop. Override storage becomes direction-aware: values in [hardMinimum, shipped) validate as today; (shipped, hardMaximum] validates only when the knob's tighten flag is on — flag-off, every read is byte-identical to current behavior. evaluateKnobDrift's alternative pool gains the declared tightening candidates so tighter findings and the apply path judge the same ladder.
• First ladder: ai_review_close_confidence (shipped 0.93) → candidates [0.95, 0.97], hardMaximum 0.97. Tightening here means a higher bar to auto-close — strictly caution-ward, the correct knob to trust first.

Boundaries held

No trigger loses coverage mid-migration: T1/T2/T4 keep their current code paths and their existing suites (55 pinning tests in auto-tune.test.ts plus the auto-apply/selftune suites) continue to pin today's outcomes; this PR adds explicit byte-stability pins for the T3 constants (RISK_MERGE_PRECISION, tighten target) so its later cutover is a deliberate diff, not drift.

[JSONbored]

Design addendum (orientation correction). The map above framed the trade as "precision must strictly improve; recall bounded" — that's the rule-firing frame. Implementation review of the corpus polarity showed the confidence-threshold classifier's positive class is predicted reversed (buildConfidenceThresholdClassifier: confidence < threshold ? "reversed" : "confirmed"), so RAISING a threshold monotonically helps recall (catches more genuinely-reversed decisions) and risks precision (withholding good ones) — the inverse orientation.

Shipped accordingly: the engine comparator is compareDirectionalBacktestScores(baseline, candidate, { mustImprove, maxSacrifice }) — the orientation is the ladder's explicit declaration, never an assumption baked into the comparator. The ai_review_close_confidence ladder declares mustImprove: "recall", maxSacrifice: 0.05. Everything else in the map is unchanged.