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.