Task: Curve review/sign-off UI: approve a bootstrapped generation before it goes official

The Official curve republish task deliberately auto-publishes a bootstrap run's output straight to output_series_id – no human gate, matching the existing raw-tick remap pattern (curve_feed_ingest_loop). That is a scope decision, not an oversight: real trading systems separate the deterministic build (bootstrap the day's quotes) from a market data control / curve QC sign-off step before a generation is treated as official and pricers are allowed to read it.

This task adds that missing sign-off layer on top of the already-published mechanism, rather than gating the write itself:

• A status on a bootstrap run's output generation (e.g. PENDING_REVIEW=/=APPROVED=/=REJECTED), distinct from whether the observations already exist in market_observations.
• Automatic QC/sanity checks surfaced to the reviewer: negative forward rates, arbitrage violations, stale or outlier pillar quotes, and day-over-day jump thresholds vs the prior generation.
• A diff view of the new generation against the prior approved one – eyeballing raw discount factors is useless without this.
• The ability to override an individual pillar's raw quote and re-bootstrap before approving, logged as an explicit override rather than a silent edit.
• An explicit approve/reject action; only an approved generation is what a "which generation is live" read actually returns to downstream consumers.

Whether "read-only downstream" continues to mean read_as_of() over the same output_series_id (return only the latest approved generation once this lands) or something new is an implementation decision for this task's own * Plan, not decided here – the republish task's acceptance criteria are unaffected either way.

Depends on the republish task (the generation this reviews) and the shared derivation-lineage task (the provenance a QC check would read).

• A bootstrap run's output generation carries a review status distinct from its mere existence in market_observations; downstream reads only ever surface an approved generation.
• QC checks run automatically against a pending generation and surface as reviewable exceptions, not just a pass/fail gate.
• A reviewer can see the new generation diffed against the prior approved one before deciding.
• A reviewer can override an individual pillar's raw quote and trigger a re-bootstrap without leaving the review screen, with the override itself recorded (who, what, why).
• Approve/reject is an explicit, audited action (who approved, when), not implicit from the generation simply existing.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Abandoned at sprint 25 close. The Qt client that this story targets was removed in sprint 25 (Retire Qt and emit the UI metadata to TypeScript).