Task: Model the driver/derived spanning-tree topology

New sibling to ores.analytics.core=/=api=/=service, not an addition to core (which pulls in the database, service and messaging layers via ores.database, ores.service, sqlgen, NATS – all persistence/CRUD for pricing-engine/model-config entities, unrelated to this). The CRM engine is pure computation and must stay a small, freestanding library that can be linked from anywhere (analytics, a future pricing service, tests) with no service/database baggage.

Proposed layout: projects/ores.analytics.quant/{include,src,tests}, target ores.analytics.quant.lib, depending only on Boost::graph, Boost::boost, and immer (new vcpkg dependency – boost-graph is already present in vcpkg.json, immer is not and needs adding). QuantLib is deliberately not introduced for this task – it is not currently vendored anywhere in the repo, and spot-day/calendar handling is supplied by the caller as plain parameters, not computed in-library.

QuantLib has a comparable ExchangeRate=/=ExchangeRateManager (Direct vs Derived rates, a chain() triangulation, graph-based lookup). Lesson taken: its own documented caveat is that when multiple chains exist "it is unspecified which one is returned" – there is no deterministic spanning-tree construction, no cycle validation, no readable errors, and no staleness concept. That gap is exactly what this task exists to close; the driver/derived vocabulary is reused, the lookup-only design is not.

Two-phase interface, matching the two very different lifecycles involved:

1. Build (rare, phase 1) – topology_builder::build(pairs, driver_assignment, majors) constructs the graph with Boost Graph (adjacency_list + disjoint_sets for incremental cycle detection as edges are added – cheaper and more precise than a post-hoc DFS), then a BFS from the pivot assigns each vertex its parent/path. Validation failures are collected across the whole input (not stopped at the first one), then raised together as a single topology_build_error exception carrying the full list of topology_error (one per offending pair), so a bad config produces one readable diagnosis ("EUR/JPY unreachable: no path via USD pivot"; "USD/JPY conflicts with JPY/USD: cycle") instead of an opaque failure or, worse, a silently picked path. Success returns an immutable crm_topology that never changes again for the lifetime of the engine. Because a second edge that would connect two currencies already unioned is rejected the moment it is seen (cycle_conflict), the resulting tree has by construction exactly one path between any two currencies – multiple paths can never arise at runtime; ambiguous configs are caught and thrown at build time, not silently resolved the way QuantLib::ExchangeRateManager resolves them today.
2. Runtime (continuous, phase 2) – rate_engine holds the fixed crm_topology plus a per-vertex cumulative "log-rate from pivot" array wrapped in immer::atom<rate_snapshot>. Representing rates as log-space cumulative sums from the pivot means any derived rate is one subtraction of two array entries (O(1)), and a batch of N pairs is one atomic snapshot load + O(N) work – no repeated locking per rate, satisfying the "hundreds/thousands of rates, quickly" requirement.
   • Updates (update(driver_quote)): since the topology is a tree, one driver edge changing only invalidates the subtree hanging below it – not the whole matrix. The engine recomputes just that subtree into a new immutable snapshot (structural sharing via immer, so only the touched entries are copied) and atomically swaps it in. This is deliberately not multi-threaded internally – the library spawns no threads – but it is thread-safe: any thread may call update(), any number of threads may concurrently call rate()=/=rates(), and neither blocks the other. A reader that loads a snapshot mid-batch never sees a torn mix of old/new values, because it holds one immutable snapshot for its whole read.
   • Staleness: each vertex's state carries the timestamp of its oldest contributing input, naturally propagated from its parent plus its own edge's timestamp (a chain is only as fresh as its stalest link). rate()=/=rates() compare that against a caller-supplied staleness_policy and return a rate_status (fresh/stale/ unavailable) alongside the value – so a stale major automatically marks every derived rate depending on it as stale, without a separate propagation pass.

• Triangulation/derivation details beyond the log-rate scheme sketched above (task 2 in the story).
• Interest-rate-aware forward-point rolling when combining legs with mismatched spot/value dates ("traveling between edges") – the =vertex_state=/edge model leaves room for this (an extra term per edge) but short-term-rate inputs and the rolling formula are out of scope for the topology task itself.
• Risk recentering (task 3) and the management UI (task 5).