Feed rule/AI-judgment calibration data into an accuracy trend view

[JSONbored]

Problem

src/services/public-accuracy-trend.ts already exists as this repo's precedent for surfacing gate-accuracy data as a trend over time. The new rule/AI-judgment fired+reversed history (#8101, #8104) and this epic's backtest scores (#8083-#8088) have no equivalent aggregate view — only the per-PR advisory comment from #8089. A maintainer has no way to see "is precision for X trending up or down over the last N weeks" without manually re-running the backtest CLI.

Area

Observability, likely extending src/services/public-accuracy-trend.ts or a sibling trend service, plus whatever surface currently renders it.

Proposal

Not scoped in detail here deliberately — the right shape depends on what real data #8101/#8104 have actually accumulated by the time this is picked up, and on whatever public-accuracy-trend.ts's current shape actually is by then. When ready: read that file's current pattern, and extend it (or add a sibling) to aggregate the new calibration data the same way.

Deliverables

Deliberately none yet — see Boundaries.

Resources

• Epic: verifiable pre-merge backtest for ORB/AMS deterministic rules #8082 (parent epic), calibration: wire linked_issue_scope_mismatch into the shared signal-tracking module (fired + reversal) #8101, calibration: wire recordRuleFired/recordHumanOverride for the remaining isConfiguredGateBlocker codes (excludes linked_issue_scope_mismatch, covered by #8101) #8104 (the data sources this would trend)
• src/services/public-accuracy-trend.ts (the existing pattern to extend or mirror)

Boundaries

Do not scope this into precise, contributor-ready requirements until #8101 and #8104 have shipped and there's real data to design the aggregation against — scoping it now risks the same premature-detail problem #8107 (the AMS epic) explicitly avoids.

maintainer-only — observability follow-up, blocked on real data existing first.

[linear-code]

JSO-5597