Investigate GPU-batched stochastic process generation

Every stochastic process implemented so far in ores.analytics.quant (GMM/geometric, arithmetic, OU, and the new Vasicek/CIR/Hull-White short-rate engines) generates one path, sequentially, on the CPU. Investigate a GPU/tensor-batched implementation capable of advancing a large number of independent process instances in one kernel launch – effectively treating a batch of processes as a tensor (instances x state dimensions) rather than one object per process – so that generating hundreds or thousands of instances simultaneously (many currency pairs, many IR curve families, many vol surface pillars) does not become a per-instance CPU bottleneck as the synthetic data generation scope grows. Investigate whether a suitable library or prior-art approach already exists (e.g. cuRAND/cuBLAS-based batched SDE simulation, JAX/PyTorch-style vectorised random-number and elementwise-op libraries usable from C++, QuantLib-adjacent GPU pricing work, or finance-specific batched Monte Carlo engines) before considering a bespoke kernel.

The synthetic market data generator's own design target (doc/analysis/gemini_ir_rates_synthetic_support.org, doc/knowledge/domain/interest_rate_curve_bundles.org) is 30-50 FX rates, hundreds of IR rates, and tens of vol surfaces generated per tick, with ores.analytics.quant deliberately kept dependency-light and free of database/messaging/refdata coupling specifically to leave room for this kind of optimisation later (see projects/ores.analytics.quant/modeling/component_overview.org). Sequential per-instance CPU generation is very unlikely to keep up once the instance count reaches that scale, especially once every IR curve family instance also has to evaluate a closed-form bond-price formula per configured tenor on every tick (see Interest Rate Curve Families). Investigating this now, before the instance count actually grows, avoids a late, disruptive rearchitecture of the process interfaces once performance becomes a blocker.

• projects/ores.analytics.quant/modeling/component_overview.org – the component's stated design rationale for staying dependency-light.
• doc/agile/versions/v0/sprint_23/ir-rates-synthetic-generation/story.org – the IR Rates synthetic data generation story whose short-rate process work surfaced this concern.

• ores.analytics.quant – the component this would apply to.
• Interest Rate Curve Families – the per-tenor, per-tick bond-price evaluation this would need to scale.