Part of #4930 → Lane A #4 (Bet 5). Build now, launch later.

Build the public /forecasts/track-record page reading the already-deployed get-forecast-scorecard endpoint. Building the UI is data-independent; only the public launch is gated (Lane C: ≥100 resolved + VOID rate <15%). Build now so it's ready the instant data crosses the bar — and so it honestly renders "N resolved, accumulating" while sparse.

Scope (shell)

• Page: rolling Brier + calibration plot, per-domain breakdown, vs-market skill, and a resolved-forecast ledger with receipts (what we said, when, at what probability → what happened → resolving source). "The only intelligence dashboard that publishes its Brier score."
• Forecast cards: detector reliability badge + family resolution history; "Resolved ✓/✗/VOID" chips (resolution fields already on get-forecasts).
• API/MCP: get_forecast_track_record tool so agents can audit accuracy before trusting (orank/agent-readiness alignment).
• Brief/digest hook: "forecast movements & resolutions" section (reuses annotateForecastChanges).
• Empty/sparse state: honest "accumulating — N resolved so far / first resolution expected ~".

Gating

Track-record summary is public (it IS the marketing); deep sim / conditional scenarios / per-detector analytics → Pro. Anon-read endpoints need cache headers + client-caller sweep (premium-gating 4xx-flood pattern).

Launch trigger (Lane C, not this issue)

≥100 resolved forecasts AND VOID rate <15%.

Related: #4930, #5007 (scorecard source), scorecard endpoint get-forecast-scorecard.