Task: Implement triangulation/derivation

Implement the CRM's runtime rate engine on top of the crm_topology from the previous task: a thread-safe (not multi-threaded), lock-free-on-the- hot-path engine that ingests a continuous stream of driver_quote ticks – possibly from a different thread than its readers – and serves batched derived-rate reads by triangulation through the pivot, with staleness propagated end to end from each contributing driver.

• domain::vertex_state, domain::rate_snapshot, domain::staleness_policy, domain::derived_rate, domain::rate_status – the runtime value types from the agreed design (see the parent task's design/ diagrams, reused here).
• service::rate_engine holds a fixed crm_topology (never mutated) and an immer::atom<rate_snapshot> (per-vertex cumulative log-rate from the pivot, so any derived rate is one subtraction of two array entries).
• update(driver_quote): recomputes only the subtree hanging off the updated edge (not the whole matrix) into a new immutable snapshot via structural sharing, then atomically swaps it in. No internal threads; safe to call from any thread.
• rate(pair) / rates(pairs): exactly one atomic snapshot load per call (one for the whole batch in the plural form), then O(1)/O(N) pure arithmetic – no locking on the read path, so a batch of hundreds/ thousands of pairs is cheap.
• Staleness: each vertex_state carries the timestamp of its oldest contributing input, propagated from its parent plus its own edge's timestamp on every update. rate()=/=rates() compare now - oldest_contributing_timestamp against a caller-supplied staleness_policy and return rate_status (fresh/stale/unavailable) alongside the value.
• A concurrent producer (update) and concurrent readers (rate=/ =rates) never block each other and a reader never observes a torn mix of old/new values within one batch – verified with a test that interleaves updates and reads across threads.
• Readable, correct triangulation: for a pair not directly on the tree, the rate is computed via the pivot path (existing crm_topology:: path_to_pivot), preferring the shorter of the two vertices' own paths (i.e. straightforward log-rate subtraction handles this without special casing, per the design).

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

Shipped the runtime rate engine in ores.analytics.quant, on top of the crm_topology from the previous task:

• New domain types: driver_quote, rate_status, staleness_policy, derived_rate, vertex_state, rate_snapshot – matching the design agreed and diagrammed in the topology task, updated where the design needed sharpening (see below).
• service::rate_engine: holds the fixed crm_topology plus an immer::atom<rate_snapshot>; a per-vertex cumulative "log-rate from the pivot" representation makes any derived rate one subtraction (exp(log_rate[quote] - log_rate[base])). update() walks only the subtree below the changed edge (via a children_ adjacency built once at construction from crm_topology::parent()) and swaps in a new snapshot via structural sharing (immer::vector::transient()=/ =persistent()); rate()=/=rates() each do exactly one atomic snapshot_.load() then pure arithmetic.
• Staleness: each vertex_state carries its own edge's tick timestamp (edge_observed_at) plus the cumulative oldest-contributing timestamp (as_of), recomputed alongside log_rate in the same subtree walk – so a stale major automatically taints every derived rate depending on it, with no separate propagation pass.
• crm_topology gained a parent() accessor (design refinement: needed by the engine to build its children adjacency and to determine, on each tick, which side of the edge is the "child" whose subtree to recompute). An edge_to_parent() accessor was added alongside it but never used, and was removed in the review round below.
• 11 new Catch2 test cases (18 total in the component, 45,000+ assertions across repeated runs): direct rate passthrough, pivot triangulation, unavailable-until-seeded, staleness propagation from the oldest contributing driver, subtree-only recompute (an unrelated branch is provably unaffected by an update elsewhere), batched rates(), reject an unknown currency, reject two known-but-unconnected currencies, reject a self-referencing pivot pair, reject a non-finite/non-positive rate, and a concurrent-update-vs-concurrent-read stress test (single writer thread + 4 reader threads, thousands of batched reads) run repeatedly with no crashes/hangs/inconsistent reads.
• Design docs updated to match: component overview, class diagram (vertex_state edge fields, rate_engine member/signature accuracy), no longer describing rate_engine as deferred.

Acceptance met in full. Story remains STARTED: risk recentering, wiring into ores.marketdata's ingest path, and the management UI are still open per the story's * Tasks plan.