Task: Curve builder UI: bootstrap config CRUD + a guided Save/Bootstrap/Publish workbench

curve_republish_service gains a compute-only path alongside its existing republish():

• compute(bootstrap_config_id, as_of) -> vector<bootstrapped_point> – everything republish() already does up to and including calling curve_bootstrap_engine::bootstrap(), minus ensure_output_series_stamped() and the market_observations=/ =observation_lineage writes. No new resolver/engine logic; this is a refactor that extracts republish()'s own read+compute steps into a reusable function republish() itself then calls, not a duplicate implementation.
• New NATS protocol pair compute_curve_request=/=response (mirrors republish_curve_request exactly: bootstrap_config_id + as_of; response carries the computed points instead of a bare success flag), new curve_republish_handler::compute() method, same has_permission pattern as republish() (a read of computed-not- published data still needs a permission check, distinct code from the publish one – marketdata::curve_bootstrap:compute vs ...:republish).
• The Workbench's Publish action still calls the existing republish_curve_request unchanged – it recomputes server-side rather than trusting client-held preview points, matching the as-of/=source_as_of= semantics observation_lineage already commits to (the raw grid could in principle have moved between Bootstrap and Publish; recomputing is the correct behaviour, not an oversight).

Static, pure, vector-in/vector-out, matching curve_bootstrap_engine::interpolate_discount_factor's own shape exactly (not std::adjacent_difference – its first-element-copy semantics don't fit an N-points-in/N-1-out transform):

• forward_rate_point { point_id; start_date; end_date; instantaneous_forward_rate; }
• forward_rate_calculator::calculate(const vector<bootstrapped_point>& points, day_count_convention_code) -> vector<forward_rate_point> – one forward rate per consecutive pillar pair, f = ln(df_start/df_end) / year_fraction(start, end), reusing day_count_calculator for the year fraction exactly like the engine's own SWAP branch does.

Built as a genuine building block per the user's explicit steer, not a one-off: takes any span of discount-factor points (not hardcoded to one config's pillar list), so it is equally usable later for whole-curve forward analysis, not just this Workbench's health-check plot. Thoroughly unit tested (flat curve -> constant forward rate, known non-flat curve -> hand-computed rates, single-point input -> empty output, day-count sensitivity).

• ir_curve_bootstrap_config's standard Qt entity artefacts (ClientIrCurveBootstrapConfigModel, IrCurveBootstrapConfigMdiWindow list, IrCurveBootstrapConfigHistoryDialog, IrCurveBootstrapConfigController) generated via codegen-add-qt-entity (--address ores.cpp.qt) into ores.qt.refdata, matching backend domain placement – same component CrmTopologyConfig's own Qt lives in. Requires adding a ** Qt drawer to projects/ores.refdata/modeling/ores.refdata.ir_curve_bootstrap_config.org first (confirmed absent – the earlier task left it out deliberately). The generated DetailDialog is discarded/unused; the Controller's New/Edit wiring is hand-edited post-codegen to construct CurveBuilderWorkbench(config_id_or_empty) instead.
• ir_curve_bootstrap_pillar gets no codegen Qt entity – no separate list window, deliberately diverging from ir_curve_template_entry's precedent (two independent flat list windows with no cross-navigation, confirmed by reading its own Qt files – not novice-friendly enough for this task's goal). Edited entirely as an in-Workbench grid (add/reorder/remove rows client-side), persisted only on the Workbench's single explicit Save action (batch save_ir_curve_bootstrap_pillars), never implicitly on tab-leave.

• CurveBuilderWorkbench (new, hand-written, ores.qt.refdata): non-modal MDI window, three tabs:

  1. Conventions – source series, curve family role, discount curve config (dropdown of existing FUNDING configs, enabled only for PROJECTION), interpolation method, day-count convention, split tenor. Per-field inline validation (e.g. Discount Curve Config required when role is PROJECTION).
  2. Pillars – the grid described above; tenor/curve-role dropdowns sourced from tenor=/=curve_role reference tables; per-row inline validation (unresolvable tenor, duplicate sequence_index).
  3. Build & Diagnostics – as-of picker, Bootstrap button, results table, zero-curve plot, forward-rate health-check plot + warning banner. Reuses CurveSnapshotMdiWindow's QtChart=/=QLineSeries dark-theme pattern (make_chart=/=style_axes helpers) rather than inventing new chart styling.

  Toolbar: Save, Bootstrap (disabled + inline hint until saved once with >= 1 pillar), Publish (disabled until a Bootstrap has run against the currently-saved recipe). Top banner for call-level/non-field errors, separate from per-field/per-row inline errors – never both for the same problem.

RefdataPlugin::setup_menus() already receives the full shared_menus_context (confirmed by reading MainWindow.cpp and RefdataPlugin.cpp), including smc.market_data_menu – currently unused by RefdataPlugin. Adds a Curve &Bootstrapping submenu onto smc.market_data_menu (not smc.reference_data_menu) with two actions: "Bootstrap Configs…" (the list window) and "Build Curve…" (blank Workbench) – the same shared-menu-contribution mechanism MktdataPlugin=/=SyntheticPlugin already use for that menu, so no new cross-component library dependency is needed; the Workbench and Controller classes stay physically in ores.qt.refdata.

• Pillar tenor/curve-role dropdowns: shipped as real dropdowns as planned (tenor reference table, ordered by its own sort_order ladder position rather than alphabetically), but Curve Role is a fixed in-code vocabulary (DEPOSIT=/=FRA=/=SWAP, mirroring bootstrap_curve_role_code), not a DB reference table – there is no curve_role table row set for this fixed enum today.
• Curve templates for novice curve-building: identified mid-build (the Pillars tab alone, even with dropdowns, doesn't tell a novice which tenors/roles a real curve needs) as a genuinely separate, larger piece of work. Shipped a cheap stopgap now (New from Existing…, clones another config's Conventions + Pillars into a blank recipe) and filed the proper curated- template-entity version as its own follow-on task (task_curve_builder_templates.org) rather than scope-creeping this one.

Each of these was caught by actually running the test scenario end to end, not by review – several were pre-existing gaps in code this task built on top of, not regressions this task introduced:

• IrCurveBootstrapConfigController was never wired into RefdataPlugin at all (missing menu registration + controller construction).
• ir_curve_bootstrap_config=/=pillar's codegen-generated NATS handlers existed but were never called from registrar::register_handlers() – the backend never subscribed to their subjects.
• MarketSeriesPickerDialog's "New Series…" never assigned a client-minted id (every other entity in this codebase mints its own).
• CurveBuilderWorkbench::setConfig() never actually loaded a config's pillars – editing an existing curve silently showed an empty Pillars tab.
• No guard anywhere (client or server) against source_series_id = output_series_id=, which would have let curve_republish_service permanently reclassify a raw input series as its own derived output on first Publish.
• split_tenor_code (a DB NOT NULL + non-empty check constraint) was never validated or auto-derived client-side, so single-segment interpolation methods always failed the check constraint at Save.
• Pillar sequence_index was assigned from Pillars-table row order, not actual maturity – entering rows out of chronological order produced a spurious "does not mature strictly after the previous pillar" engine failure despite every individual pillar being valid.
• Two hardcoded, never-seeded change_reason_code literals (system.derived_series, system.curve_bootstrap) in curve_republish_service.cpp made every first Publish fail – fixed by seeding the (already sensible, already-representative) codes the write path intended, not by adding a change-reason picker to an automatic system write. CurveBuilderWorkbench's own Save action was missing a real change-reason prompt entirely (hardcoded a third, also-unseeded literal) – fixed with the standard ChangeReasonDialog=/=ChangeReasonCache flow every other detail dialog already uses.
• curve_republish_service::republish() minted a fresh random id for every observation_lineage row on every call, so re-publishing the same (series, as-of, point) natural key always hit the natural-key unique index instead of the intended close-prior- row/insert-new-version behaviour the table's own doc comment describes.
• MarketSeriesPickerDialog=/=BootstrapConfigPickerDialog only ever showed genuine server errors inline, never in the standard copiable MessageBoxHelper::critical box every other dialog uses.

Also filed two capture-level design gaps surfaced along the way, deliberately not fixed here since each needs its own design pass: strongly-typed market_series index/currency filter fields (currently string-matching a free-text qualifier) and Qt codegen has no UUID-to-friendly-name mechanism for list columns.

Verification: full local build clean (linux-clang-debug-make); rat 0 failures across the whole suite. Manually verified end to end via the test scenario above, iterating through several real rounds of Save/Bootstrap/Publish against the seeded Acme Corporation data until a full 7-pillar desk-standard curve (DEPOSIT 1M/3M/6M/12M, SWAP 2Y/5Y/10Y) bootstrapped and published successfully.