Story: Cross-rates matrix (CRM)

Implement the FX cross-rates matrix in ores.marketdata so derived rates are computed from drivers and the matrix is always arbitrage-free — the consistency engine the architecture relies on.

• Driver/derived spanning-tree topology with cycle detection (never set both sides).
• Derived rates computed by triangulation through the pivot; direct preferred.
• Risk recentering (star-shaped on the aggregation currency) supported.
• A management UI to view/edit drivers and inspect derived rates.

Planned tasks (not yet scaffolded as task docs), following the domain model's concept map:

1. Model the driver/derived spanning-tree topology (CRM graph topology and spanning tree): the graph structure over currency pairs, cycle detection so a pair is never set on both sides (driver and derived simultaneously).
2. Implement triangulation/derivation (Triangulation and cross rates, spot rate derivation mechanics): compute a derived rate from the spanning tree via its pivot currency, preferring a direct driver-to-driver quote over a multi-hop path when both exist.
3. Implement risk recentering (CRM risk: recentering and artefacts): re-root the tree star-shaped on a chosen aggregation currency without changing the derived rates' actual values.
4. Wire the CRM into the ores.marketdata authority's ingest path (see Market Data Architecture): producers publish driver rates only; the CRM computes and publishes the derived set on the official tenant-scoped stream.
5. Management UI: view/edit drivers, inspect derived rates and the current spanning-tree structure.

• Auto-refresh is allowed for the CRM cross-rates matrix UI (and other trading-related UIs), on a client-side polling timer – this does not reopen the earlier "never broadcast the derived set" decision. That decision (see the service-wiring task's "compute locally where possible, pull on demand otherwise" note) is about the server never pushing/broadcasting derived ticks to every subscriber – it says nothing about a client choosing to automate its own on-demand pulls. A UI timer that calls marketdata.v1.crm.rates every N seconds is exactly the same request/response the manual Reload button already makes, just automated – no new server-side fan-out, no NATS subscription. Traders actively watching a screen (CRM matrix, and likely other trading-related panels going forward) need it to update without a manual click; that's a real, common requirement this story initially under-scoped by conflating "no server broadcast" with "no client polling". Follow the existing ServiceDashboardMdiWindow auto-refresh pattern (checkable toolbar action + configurable interval, off by default) rather than inventing a new one.
• The CRM lives in a new, dependency-light component – ores.analytics.quant – not in ores.analytics.core (which is persistence/CRUD for pricing-engine entities, unrelated). It links only Boost::graph=/=Boost::boost and immer; no database, service, messaging, or refdata coupling. Everything domain-specific (currency codes, spot days, short-term rates) is a caller-supplied parameter, not fetched by the library.
• Two-phase interface: a rare, one-shot topology_builder::build() that validates and returns an immutable crm_topology, and a continuous rate_engine (later task) that consumes driver-rate ticks and serves derived-rate reads.
• Ambiguous input (more than one path between two currencies) is always rejected at build time via incremental union-find cycle detection (boost::disjoint_sets) – never silently resolved. This is a deliberate departure from QuantLib::ExchangeRateManager, whose own docs admit undefined behaviour when multiple chains exist.
• The runtime engine will be thread-safe without being multi-threaded itself: no internal threads, concurrency safety via an atomically-swapped immutable snapshot (immer::atom), so updates and batched reads never lock against each other.
• QuantLib is deliberately not introduced as a dependency for this story (not currently vendored anywhere in the repo); spot/calendar handling stays a caller-supplied parameter.
• Rates are represented as cumulative log-rate-from-the-pivot per vertex (not per-pair), so any derived rate is one subtraction and one update() only touches the subtree below the changed edge – crm_topology exposes parent() to support this (an edge_to_parent() accessor was added alongside it but never used, and was removed in review). Staleness is carried as a per-vertex timestamp alongside the log-rate, recomputed in the same subtree walk rather than as a separate pass. The pivot's own as_of is seeded to the maximum time_point (never the limiting factor), not construction time – an early version wrongly used construction time, which floored every other vertex's freshness at that instant forever; caught by the recentering task's tests.
• rate_engine::update() is single-producer by design (concurrent writers are not supported/needed); rate()=/=rates() are safe from any number of concurrent reader threads. This is documented on the class, not enforced at compile time.
• Risk recentering (service::recenter) is a point-in-time snapshot transform, not a live/continuous one: it builds a fresh star-shaped crm_topology around the aggregation currency (reusing topology_builder unchanged – a star can never conflict), and seeds the new engine with each currency's current rate and original as_of pulled from the source engine, so recentering never fabricates freshness. rate_engine gained an explicit move constructor (loading the moved-from immer::atom's value into a fresh one) since recenter must return a new engine by value and immer::atom itself disallows copy/move.
• The intermittent SIGSEGV/SIGABRT reported against rate_engine's concurrency test traced to a test bug, not a production one: Catch2's REQUIRE=/=CHECK macros are not thread-safe, and the test's reader threads were calling them directly. A standalone ThreadSanitizer build (compiled ad hoc with clang++ -fsanitize=thread, since TSAN isn't wired into any CMake preset) found zero races in rate_engine=/=crm_topology=/=immer::atom itself under the exact conditions that reliably crashed the real binary – that null result is what redirected the investigation to the vcpkg-prebuilt libCatch2.a (not TSAN-instrumented) and its documented not-thread-safe assertions. No production code changed; only the test collects results via std::atomic<int> and asserts on the main thread after joining.
• Inversion (1/rate fallback) and %-change-vs-previous are served-side concerns, not part of rate_engine itself: rate_inverter is a stateless pure function over a batch of already-computed derived_rate=s, and =rate_delta_tracker is a separate, thin stateful decorator (mutex-guarded, keyed by the displayed (base, quote) pair) layered on top of rate_engine rather than folded into it. This keeps rate_engine's own immer-snapshot-per-batch concurrency model untouched, and keeps "what did this specific (tenant, party, crm_name) scope last see" – a serving-time/session concept – decoupled from the market/topology engine itself. One rate_delta_tracker instance is owned per named engine in crm_ingest_bridge, reset on every refresh() the same way the engine's own accumulated state is.
• Convention-aware display formatting (precision, base/quote canonical ordering) is explicitly out of this story's numeric-logic-extraction scope: it was never implemented anywhere (client or server) to begin with, so there was nothing to extract. Filed as a separate follow-up task for a plain C++ presentation overlay in ores.marketdata.client, since it is net-new functionality with its own design questions (server- vs. client-side convention caching).
• The FX pair convention cache this formatter needs lives in a new ores.refdata.client component, not inside ores.qt or ores.marketdata.client – client is a documented, catalogue-level specialist sub-component role (projects/modeling/component_architecture.org, "consumer-facing API without coupling consumers to core internals"), used the same way party_cache uses ores.iam.core for its own single-consumer case. The general placement rule (producer never caches itself; single consumer gets the cache in its own component; multiple UI-layer consumers share a thin *.client component) is captured as its own knowledge doc, Where should an entity-mirror cache live?, for future cached_by decisions to reference rather than re-litigate.
• Generalised the nats-event-cache codegen facet's cached_by flag to accept the existing component.subcomponent dotted form (cached_by: refdata.client) instead of hardcoding a .core subcomponent – no new model flag, purely derived, verified byte-identical regeneration of the one prior consumer (party_cache). Also fixed two facet-level bugs this new second consumer surfaced that party_cache had only ever avoided by accident: a missing reflectors.hpp include needed for rfl::json on any tenant_id=/=uuid-bearing entity, and load() silently swallowing failures instead of returning them (now [[nodiscard]] std::string, empty on success) so a UI consumer isn't stuck tailing logs to find out why nothing loaded.
• The convention-aware CRM rate formatter (ores.marketdata.client/presentation/crm_rate_formatter) needs only a resolved decimal_places int, not the full currency_pair_convention or currency.base_precedence: a CRM cell's (base, quote) orientation is already fixed upstream by rate_inverter=/=crm_rate_view, and base_precedence only matters when a convention is captured (deciding which direction becomes the stored pair_code), not when it's looked up for an already-oriented pair. "Base/quote reordering" is instead a direction-agnostic lookup concern, handled by CrmCrossRatesMatrixMdiWindow trying the cell's pair-code in both directions against currency_pair_convention_cache before falling back to the formatter's own fixed default precision.

• Correlation management and volatility-surface driving (Correlation management, Volatility surface driving) — these reuse the same driver/derived pattern but for a different asset class; separate future stories once the CRM mechanism itself is proven on FX spot.
• Spot rate governance workflow (local/global approval, Spot rate governance) — an operational process layered on top of the CRM, not part of building the CRM itself.