Story: IR curve bootstrapping + official curve republish

Working through what a persisted, bootstrapped curve object actually is (see Multicurve Management's "curve template" requirement) surfaced a gap this story must close rather than inherit: reusing the existing market_series=/=market_observations tables for bootstrapped output (the same pattern the CRM's computed crosses would eventually use, and the same shape ores.synthetic's raw-tick storage already uses) is architecturally correct — it is the established pattern here, applied a third time, not a new one — but doing so without a lineage mechanism would leave "was this point observed or computed, and by what" unanswerable except by guessing from the source string, which is exactly CRM's current soft spot (CRM's derived crosses are pull-only today — see crm_handler's "never broadcast the full derived set as ticks" — so this gap is latent there, not yet realised in storage; this story should not add a second, curve-specific version of the same weakness).

Three design decisions this story now commits to, detailed in the tasks below:

• Shared, generic lineage — a derivation_kind marker on market_series (sentinel 'OBSERVED', matching the existing curve_role'NONE'= convention on instrument_codes rather than a nullable column) plus a per-observation observation_lineage side table, deliberately generic so CRM can reuse it unchanged whenever it starts persisting derived crosses — not this story's job to change CRM itself, but its job not to build something CRM would later have to duplicate.
• Bootstrap config as refdata, not marketdata — recipe/config entities consistently live in ores.refdata in this codebase (crm_topology_config, curve_role, tenor); the bootstrap config follows that placement, reusing tenor and curve_role directly rather than inventing parallel concepts.
• Build order as data — the Funding-before-Projection dependency (Multi-Curve Construction) is encoded via a self-referencing discount_curve_config_id on the bootstrap config (nil-uuid sentinel for Funding, required for Projection), so a Projection curve's bootstrap run has an explicit, queryable dependency rather than an implicit ordering assumption.

Every nullable field considered during design was replaced with either a sentinel paired to a discriminator column (curve_family_role FUNDING -> nil discount_curve_config_id; 'OBSERVED' -> nil derivation_config_id) or, where the null represented a genuinely avoidable gap (output_series_id before first publish), removed by minting the output series row at config-creation time instead.

Save (persist recipe) / Bootstrap (compute preview) / Publish (make live) stay three separate, explicit UI actions calling three separate backend paths, not two or one – confirmed mid-build as a genuine domain distinction, not just a UI nicety. The backend split this required (curve_republish_service::compute() alongside republish()) is also the foundation the still-BACKLOG sign-off/review task needs, since it cannot gate "publish" behind an approval step while compute and publish stay fused.

ir_curve_bootstrap_config's backend stays in ores.refdata (matching crm_topology_config, tenor, other recipe/config entities), but its Qt surface registers under Market Data's shared menu. General rule worth keeping for future entities: config/convention entities that are looked up and referenced stay Reference Data; entities whose primary purpose is producing or triggering the production of a market data series surface under Market Data regardless of backend component ownership.

A novice cannot build a curve from a blank Pillars tab with no guidance on which tenors/roles a real curve needs – identified mid-build as a genuinely separate, larger piece of work (a curated, admin-maintained template entity), not something to retrofit into this task's own scope. Shipped a cheap "New from Existing…" clone-a-config stopgap now; filed the proper version as its own follow-on task.

Filtering market_series by currency/index (needed so the Workbench can constrain which raw series a curve bootstraps from) currently means substring-matching a free-text qualifier column – already caused one real bug (a floating_index_type code's dash-vs-slash convention silently diverging from market_series.qualifier's own). The oresmd migration in flight elsewhere does not resolve this by itself (it only standardises qualifier generation, still as a plain string, not a queryable typed field). Captured, not fixed here: strongly-typed market_series index/currency filter fields.