Task: Migrate ir_curve_generation_config onto oresmd, add curve role

• ir_curve_generation_config.index_name is free text holding the full floating_index_type.code (e.g. "USD-SOFR"), validated by the generated single-argument FK validator ores_refdata_validate_floating_index_type_fn(tenant_id, value) wired via the model's * Insert trigger / Validations table (doc at projects/ores.synthetic/modeling/ores.synthetic.ir_curve_generation_config.org).
• No role field exists at all today – curve_feed_controller (projects/ores.synthetic/service/src/curve_feed_controller.hpp) treats any two feeds with the same qualifier = currency_code + "/" + strip_currency_prefix(index_name) as an unconditional conflict (find_qualifier_conflict), so a discount curve and a projection curve for the same currency+index can never coexist – exactly the gap this task closes.
• ir_curve_feed.cpp's strip_currency_prefix() and resolve_vintage_initial_rate()'s qualifier construction (currency_code + "/" + strip_currency_prefix(...)) are the two real consumers building a market-data qualifier string out of index_name today; both need to build it from index_family=/=tenor instead once index_name is gone.
• overnight_index_convention=/=ibor_index_convention both store their id as the full "CCY-FAMILY" code too (e.g. "USD-SOFR", "EUR-EURIBOR") – no tenor in their own id; term-index tenor variants (e.g. 3M EURIBOR vs. 6M EURIBOR) live at the ir_curve_template_entry grain already, which is exactly why oresmd models tenor as a query key separate from index.

Checked whether each new field can reuse an existing entity via a soft FK + dynamic_combo, per the project's own convention (book.status=/=tenor.kind=/=counterparty_identifier.id_scheme etc. are all dynamic_combo over a real lookup table with a ores.qt/LookupFetcher.hpp fetch_* function; business_unit.status is a static_combo for a fixed value set with no backing entity).

• role: no existing entity enumerates discount/projection/self_discounting – it is intrinsic classification of this record, not a reference to something else. static_combo (like business_unit.status's Active,Inactive,Closed), no soft FK, no new fetch function needed.
• tenor: ores.refdata.tenor already exists as a real lookup entity, and its sibling ir_curve_template_entry.start_tenor_code=/=end_tenor_code are already soft-FK'd to tenor.code – but rendered as plain line_edit, not a combo (an existing gap in that sibling entity, out of scope here but worth its own follow-on capture). No fetch_tenor_codes=/=fetch_tenors function exists in LookupFetcher.hpp today. This field should be dynamic_combo over tenor.code, which means adding that fetch function as part of this task (reusing the existing tenor entity via a real soft FK, not free text) rather than a line_edit that would repeat the sibling entity's gap a second time.
• index_family: no single entity enumerates exactly the oresmd index_family set – valid values come from combining overnight_index_convention=/=ibor_index_convention rows (each row's id suffix after currency_code + "-"). Checked whether the Qt codegen combo facet supports a combo scoped/filtered by a sibling field's live value (i.e. "only show families that have a convention row for the currency_code currently selected") – it does not: every existing fetch_* function in LookupFetcher.hpp takes only a ClientManager*, none take a scoping parameter tied to another field, so a currency-scoped cascading combo would be new Qt/codegen plumbing, not just new data. Revised while implementing Step 1 (after reading the actual dynamic_combo=/=static_combo mustache branches in cpp_qt_detail_dialog.cpp.mustache): every worked dynamic_combo example in the codebase populates from a real, persisted domain struct via an object-list combo_fetch_fn; inventing a synthetic, non-persisted "index family" struct purely to keep the widget type dynamic_combo would mean adding a new cross-table aggregation query, a new NATS request/response, and a new domain type for a six-value, effectively-fixed vocabulary (index_family is itself a closed C++ enum, not user-editable data) – disproportionate for what the widget needs. index_family is therefore static_combo (fixed libor,euribor,sofr,estr,sonia,tona values), not a soft FK at the widget layer. The actual "reuse existing entities" requirement is still met where it matters: the Step 2 composite trigger validator rejects any (currency_code, index_family) combination that doesn't resolve to a real overnight_index_convention=/=ibor_index_convention row, so the soft-FK enforcement happens server-side against the real tables, just not via the combo's data source.
• tenor (confirmed while implementing Step 1): dynamic_combo over refdata::domain::tenor (combo_code_field: code, combo_display_field: display_name, combo_tooltip_field: description, combo_sort_field: sort_order), matching the calendar_exception.calendar_code -> fetch_calendars worked example exactly – a real object-list fetch against a real persisted entity, backed by a new fetch_tenors(ClientManager*) (Step 3).

Edit projects/ores.synthetic/modeling/ores.synthetic.ir_curve_generation_config.org (done):

1. Deleted the index_name natural-key column and its ores_refdata_validate_floating_index_type_fn trigger validation.
2. Added index_family (text, not nullable) – static_combo (fixed libor,euribor,sofr,estr,sonia,tona values; see revised widget survey above), and validated server-side by a new composite validator (Step 2), not a bare enum CHECK, since it must resolve against real convention rows.
3. Added tenor (text, not nullable, empty-string-when-absent – same pattern as vintage_source=/=vintage_date) – dynamic_combo over refdata::domain::tenor backed by a new fetch_tenors (Step 3), with a SQL check: required (non-empty) iff index_family in ('libor','euribor'), empty otherwise (overnight families have no tenor dimension, mirrors oresmd's own index_family-conditional grammar).
4. Added role (text, not nullable, default self_discounting for backward-compatible seed data) – static_combo with a SQL check: one of discount=/=projection=/=self_discounting.
5. Updated the generator block, Qt Detail fields table, and Qt model Columns table to replace index_name with index_family=/=tenor=/=role.

The codegen Insert-trigger Validations mechanism only supports fn(tenant_id, NEW.column) (one column in, one value out) – it cannot express "look up currency_code + '-' + upper(index_family) against two possible tables." This needs a hand-written PL/pgSQL trigger function (following the same pattern ores_synthetic_ir_curve_generation_configs_notify_trigger_create.sql already uses for hand-written trigger logic beyond what codegen generates), added as a second trigger alongside the codegen-generated one: raise if neither overnight_index_convention nor ibor_index_convention has a row whose id = NEW.currency_code || '-' || upper(NEW.index_family).

Run the codegen-add-entity (or narrower codegen-add-sql-schema + codegen-add-cli-entity=/etc. as needed) skill/profile against the edited model, or the underlying =compass codegen invocation directly, to regenerate: SQL create/drop scripts, domain struct, table/json_io, repository entity/mapper, Qt detail dialog/list model/history dialog, generator. Diff the regenerated files against a scratch copy of the current ones to confirm only the intended fields moved.

Hand-write the one new LookupFetcher.hpp=/.cpp= function the tenor dynamic_combo needs (never codegen-generated – every existing fetch_* is hand-written against the relevant service/repository query): fetch_tenors(ClientManager*) returning std::vector<refdata::domain::tenor>, matching the existing fetch_calendars=/=fetch_book_statuses object-list shape exactly. index_family needs no new fetch function (static_combo, per the revised widget survey above).

• ir_curve_feed.cpp: replace strip_currency_prefix() + string concatenation with a construction from cfg.currency_code, cfg.index_family, cfg.tenor (both call sites: the tick qualifier_ passed into the feed, and resolve_vintage_initial_rate's lookup qualifier). Confirm against ores.ore/core's market_series_key_registry what shape the RATES/YIELD qualifier is actually expected to have post-migration – this is the one point where "what string do we publish" needs to agree with whatever already-published/consumed vintage data expects, so check compatibility before assuming a 1:1 rename.
• curve_feed_controller.hpp: change running_feed to carry the four fields (or a small tuple/struct) instead of a single qualifier string; find_qualifier_conflict=/=running_source_name_for_qualifier compare on (currency_code, index_family, tenor) while explicitly excluding role from the conflict key comparison itself (i.e. two running feeds only conflict when everything except role matches and role does NOT differ) – ADD a positive test asserting a same-tuple-different-role pair does not conflict, and the existing same-tuple-same-role pair still does.
• Qt: ClientIrCurveGenerationConfigModel, list/detail/history dialogs, IrCurveEditor.cpp, IrCurveGenerationConfigController.cpp, SyntheticBindingDialog.cpp, MarketSimulatorWindow.cpp – all read index_name today (list column, detail-dialog field, window titles/labels); each becomes index_family=/=tenor (possibly recombined for display, e.g. "SOFR" or "EURIBOR 3M").
• Generator (ir_curve_generation_config_generator.cpp): replace the hardcoded index_name fixture with index_family=/=tenor=/=role fixtures consistent with whatever seed conventions rows exist.

Close Normalize floating-rate index reference data with a * Result pointing back here, per the parent story's existing * Decisions entry.

Full compass build + ctest (same bar as the previous task in this story); specifically extend/add curve_feed_controller=/=ir_curve_feed unit tests for the discount-vs-projection non-conflict case and the (currency_code, index_family) composite-validator rejection case. No DB rows exist in this environment to migrate/backfill against (per the previous task's experience), so there is no live-data migration script to write here – this is a schema-shape change on an as-yet-unpopulated table in this environment.

• Does ores.ore/core's real market_series_key_registry=/ORE XML round-trip (a *later* task on this story) already assume a specific =RATES/YIELD qualifier shape that constrains how index_family=/=tenor must combine into that lookup string? Worth a quick check before Step 4 so the qualifier construction isn't reworked twice.
• Confirm role's default (self_discounting) is the right backward-compatible choice for the (currently empty) table, vs. requiring it be explicit with no default.