Story: Market data notation: design an ORE Studio canonical URN mapping to ORE/Bloomberg/Reuters

ORE Studio currently addresses market data ad hoc and inconsistently across components:

• fx_spot_generation_config has an explicit ore_key field (FX/RATE/EUR/USD), derived deterministically from the currency pair.
• ir_curve_generation_config has no equivalent field at all. The only identifier is the (currency_code, index_name) pair, and curve_feed_controller enforces at-most-one-running-feed-per-qualifier using that pair as an opaque string key – a pragmatic runtime stopgap (see Source vintage historical IR rate dataset), not a real identifier scheme.
• Neither matches how ORE itself addresses market data, which – per the ORE market data catalogue and external/ore/examples/ – actually uses three distinct, non-interchangeable key types depending on context: (1) an index name (USD-LIBOR-3M, matches our floating_index_type.code), (2) a curve/market key (Yield/USD/USD3M, format Yield/<CCY>/<CURVE_ID>, defined in todaysmarket.xml=/=curveconfig.xml), and (3) a raw quote key (MM/RATE/USD/2D/3M, IR_SWAP/RATE/USD/2D/3M/2Y, format TYPE/SUBTYPE/dim1/dim2/...). The literal string "LIBOR" never appears in any of the three – the index identity is carried by the CURVE_ID or by convention lookups, not by the key itself.
• The existing Market Data Identifier doc already documents ORE Studio's own <series_type>/<metric>/<qualifier>[/<point_id>] canonical key (used for market_series=/NATS routing) -- but this scheme predates, and was not reconciled against, the three-key ORE addressing model above, nor does =ir_curve_generation_config participate in it at all.

This story's goal is to resolve that inconsistency with a single, deliberately-designed identifier scheme: research how ORE, Bloomberg, and Reuters/Refinitiv actually address interest-rate (and, where it clarifies the general shape, FX) market data, catalogue precisely where ORE Studio's current identifiers fail to project onto ORE's own conventions, and design a canonical ORE-Studio-native notation – referred to provisionally as a "market data URN" – with explicit structured fields (currency, index/benchmark, tenor, curve role: discount vs projection, instrument type) from which every supported external notation (ORE index name, ORE curve key, ORE quote key, and optionally Bloomberg/RIC) can be deterministically derived. The output of this story is the design – the state-of-the-art survey, the gap analysis, and the proposed notation and projection rules – not a rewrite of curve_feed_controller or the generation-config schemas; implementing the design is deferred to follow-on tasks/stories once the notation itself has been reviewed and agreed.

• A state-of-the-art survey exists covering how ORE, Bloomberg, and Reuters/Refinitiv each address interest-rate market data (index fixings, curve/market keys, and raw quotes), building on and reconciling the existing Market Data Identifier and ORE market data catalogue docs rather than duplicating them.
• The survey documents ORE's three-key model precisely (index name, Yield/<CCY>/<CURVE_ID> curve key, TYPE/SUBTYPE/dim... quote key) with worked examples for at least USD-LIBOR-3M, USD-SOFR, and one swap and one FX instrument, sourced from external/ore/examples/.
• A gap analysis enumerates, concretely, every place ORE Studio's current identifiers (fx_spot_generation_config.ore_key, ir_curve_generation_config's (currency_code, index_name) pair, curve_feed_controller's qualifier, the market_series series_type/metric/qualifier key) fail to project onto ORE's real addressing scheme, including the specific problem that triggered this story: a tenor-specific index (e.g. 3M vs 6M LIBOR for the same currency) has no distinguishing key today beyond index_name string content, and there is no explicit discount-vs-projection curve-role field anywhere in the schema.
• A canonical ORE Studio notation is proposed: field list, textual grammar, worked examples for the same instruments as the survey, and explicit, deterministic projection rules into each of ORE's three key types (and Bloomberg/RIC where the mapping is unambiguous).
• The proposal explicitly states its relationship to the existing <series_type>/<metric>/<qualifier>[/<point_id>] market_series key and to fx_spot_generation_config.ore_key – superset, replacement, or coexistence – with a stated rationale.
• The story explicitly scopes out schema changes, curve_feed_controller rework, and any code implementing the new notation – those are follow-on work once the design is reviewed.

• This story produces a design, not an implementation: no schema migrations, no curve_feed_controller changes, no rewrite of the existing market_series key or ir_curve_generation_config. The current qualifier-based collision check added in Source vintage historical IR rate dataset stays as-is; it is functionally correct for its narrow purpose (preventing two auto- started feeds from binding the same tenant/currency/index) even though it does not model curve-family relationships or ORE's real key shape.
• The ORE market data catalogue and external/ore/examples/ are the primary sources for ORE's own notation – already researched this session; the LIBOR-key finding (index name never appears standalone in the ORE curve/quote key formats, only via CURVE_ID convention lookup) is documented there and should be cited, not re-derived.
• The canonical notation is a real RFC 3986 URI, scheme oresmd (oresmd://<asset_class>/<entity>?...), not the flat colon-delimited "URN" the story's own title provisionally called it – optional metadata (tenor, curve role, index family, …) lives in the URI's query string, conditional per asset class, rather than in fixed path positions, so one grammar covers every asset class without NONE placeholders or per-asset-class variants. See oresmd: ORE Studio Market Data URI's "Why a URI, and why query parameters" section for the hierarchical alternative considered and why it was not adopted.
• oresmd spans both the logical (requirement) and physical (resolved instance) levels Market Data Requirement distinguishes – a partially-specified URI is a requirement, a fully-specified one is a resolved instance – rather than only ever representing the physical side.

• Any implementation of the proposed URN in code or schema (tracked as future follow-on work once the design is agreed).
• Real-data vendor feed integration for Bloomberg/Reuters (the existing ric=/=bbg_ticker reference-only fields on market_series already anticipate this; this story does not change that plan).
• Rework of curve_feed_controller's qualifier-based collision logic.