Task: Survey ORE, Bloomberg, and Reuters market data notations

Produce one consolidated survey document (extend the existing market data identifiers doc rather than fork a new one) of how each notation actually addresses interest-rate market data, distinguishing the index/fixing identity from the curve identity from the raw quote identity in each scheme:

• ORE: already confirmed this session via the ORE market data catalogue and external/ore/examples/ – index name (USD-LIBOR-3M), curve/market key (Yield/<CCY>/<CURVE_ID>, e.g. Yield/USD/USD3M, from todaysmarket.xml=/=curveconfig.xml), quote key (TYPE/SUBTYPE/dim1/dim2/..., e.g. MM/RATE/USD/2D/3M, IR_SWAP/RATE/USD/2D/3M/2Y). Cite, don't re-derive.
• Bloomberg: the existing doc already has FX/rates/equity/credit/ commodity ticker tables (SOFRRATE Index, EUR006M Index, USSA5 Curncy). Extend with the yellow-key taxonomy (Index/Curncy/ Corp/Govt/Comdty) and how a curve (as opposed to a single fixing) is addressed on Bloomberg (e.g. curve members via DES=/=YCRV vs a single ticker).
• Reuters/Refinitiv (RIC): the existing doc already has FX/rates/ equity/credit/commodity RIC tables. Extend with how a full curve (not just one tenor point) is addressed (chain RICs / curve RICs) since that's the gap most relevant to the IR curve-config problem.

The output should let a reader answer, for any given real-world rate (e.g. "6M EUR EURIBOR" or "USD SOFR OIS 5Y par swap rate"), what its identifier looks like in all three schemes side by side.

• The market data identifiers doc gains a side-by-side comparison table (or section) covering index/fixing, curve, and quote-level addressing for ORE, Bloomberg, and RIC, for at least: 3M and 6M USD LIBOR, USD SOFR, EUR EURIBOR 6M, EUR ESTR, one par swap rate, and one FX spot pair (for continuity with the existing FX rows).
• The ORE section is sourced from external/ore/examples/ file paths cited inline (e.g. Input/todaysmarket.xml, Input/curveconfig.xml), not invented.
• Explicitly states, per scheme, whether a curve (a family of tenor points) has its own identifier distinct from any single tenor's fixing identifier – this is the crux fact the design task depends on.

(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.

Produced the eight-document knowledge cluster (hub + Requirement, Identifier, Universe, Configuration, Dependency Resolution, Snapshot, Filtering) formalising how a logical market data requirement resolves into a concrete identifier, expressed as set operations over a market data universe, with terminology confirmed against ORE and OpenGamma Strata source rather than carried over unreviewed. This PR closes out the writing pass on that cluster: fixed a duplicated "The running analogy: DNS" heading in the hub note, and restructured "How to read this cluster" into two named lenses (analogy, notation) since both are core content every document in the cluster assumes rather than optional asides – dropping the note-box styling that had wrapped them accordingly, while keeping note-boxes for the genuinely skippable CIDR digressions in Requirement and Identifier.