Fix shared-RNG data race in saveat_regression ensemble test

[ChrisRackauckas-Claude]

Ignore until reviewed by @ChrisRackauckas.

Problem

test/saveat_regression.jl shares a single StableRNG(12345) across every trajectory of an EnsembleProblem solved with the default EnsembleThreads(). Under multithreading (JULIA_NUM_THREADS=auto/8), worker threads concurrently mutate the one LehmerRNG, racing on its internal state. The corruption produces degenerate trajectories, the ensemble mean no longer tracks exp(-10t), and roughly 190/202 of the rtol=0.1 assertions fail nondeterministically. This is a flaky failure observed on master's own Tests (lts/pre, InterfaceII) jobs. Single-threaded the test passes 202/202.

Fix

Give every trajectory its own independent, seeded StableRNG via the EnsembleProblem prob_func, keyed off ctx.sim_id. This makes the threaded solve race-free and reproducible.

• Does not switch to EnsembleSerial() — the threaded path is still exercised.
• Does not loosen the rtol — it remains a real rtol=0.1 regression check.
• Preserves the original per-solve save_positions ((false, false) for the saveat solve, the DiscreteProblem default (false, true) for the interpolated solve), so the statistical intent is unchanged.

Only test/saveat_regression.jl is touched. File is already SciMLStyle-formatted (JuliaFormatter v2, no diff).

Verification (run locally, multithreaded, latest deps)

Isolated depot, JumpProcesses 9.29.0 / DiffEqBase 7.5.5 / SciMLBase 3.18.0 / StableRNGs 1.0.4.

Before (unmodified master):

# Julia 1.10, JULIA_NUM_THREADS=8 (3 runs) and Julia 1.11, 8 threads
saveat_regression (wrapped) |   12   190    202   # FAIL, every run
# single-threaded: 202 202  (passes)

After (this PR):

# Julia 1.10, 8 threads x4:   202 202
# Julia 1.10, auto/128 threads: 202 202
# Julia 1.11, 8 threads x3:   202 202

Passes deterministically across all repeated multithreaded runs.

🤖 Generated with Claude Code

[isaacsas]

Shouldn't the current SciMLBase handle this case even without the JumpProcesses 10 changes? I thought we tested jumps with threading there?

[ChrisRackauckas-Claude]

You're right that SciMLBase handles the thread-safety here — thanks for pushing on it; I had the mechanism mischaracterized. Digging in against the actually-resolved stack (SciMLBase v3.18.0 + JumpProcesses v9.29, Julia 1.10.11 and 1.11.9):

SciMLBase v3.18's threaded ensemble path does isolate the JumpProblem — for safetycopy=false + an AbstractJumpProblem it deepcopies the problem once per task into task_local_storage()[:_ensemble_jump_prob] (basic_ensemble_solve.jl:524-539). I instrumented the original test: 200 trajectories on 8 threads touch exactly 8 distinct RNG objects (1 single-threaded). So there is no live data race — my "data race" framing was wrong for this version (it fits the old v2.x path where the per-thread jump deepcopy was dead code). I've corrected the commit message.

What actually breaks is statistical and deterministic: solve gets seed=nothing, so every per-task deepcopy starts from the identical StableRNG(12345) and replays the same stream → the ensemble collapses to ~n-threads distinct trajectories and the rtol=0.1 mean stops tracking exp(-10t). Measured: single-threaded 202/202; 8 threads a deterministic 6/101; 128 threads worse. This is exactly what ensemble_problems.jl's "EnsembleThreads: no data race" testset documents ("deepcopy'd problems on non-main threads start with identical RNG states... uniqueness requires explicit seeding") — which is why thread_safety.jl and that testset only assert completion, not statistics. So nothing's broken in SciMLBase.

Two clean ways to make the saveat regression pass under threads (both verified 101/101 multithreaded):

1. Drop the explicit rng and rely on JP's DEFAULT_RNG = Random.default_rng() (per-task, thread-safe) — simplest, but non-reproducible run-to-run.
2. Per-trajectory seeded StableRNG via the EnsembleProblem prob_func keyed on ctx.sim_id (this PR) — race-free, reproducible, same idiom as ensemble_uniqueness.jl.

I went with (2) for reproducibility; happy to switch to (1) if you prefer minimalism. Either way the commit message now describes this as RNG-stream degeneracy under threading (race-free), not a data race.