Solver extension investigation: beyond fixed-step RK4

[yktsnd]

The current solver is classical fixed-step RK4 (dt from the model config, every step stored). This is an explicit implementation choice for the demonstration model (docs/numerical-method.md, ADR 0001/0004) and is unsuited to stiff systems — instability now surfaces as a typed invalid SimulationResult rather than being clamped, but it still means some parameter regimes are simply out of reach.

Investigation scope

• Fixed RK4 limitation: characterize the stable region for first-order networks at the current dt, and which future model classes (stiff, widely separated rate constants) fall outside it.
• Adaptive solver criteria: what would justify adopting an adaptive-step method (e.g. embedded RK45/Dormand–Prince) — accuracy targets, worst-case step counts, deterministic reproducibility requirements.
• Error estimation: how a local error estimate would feed the existing Diagnostics/NumericalError reporting instead of silent step rejection.
• Performance: frame-storage strategy when steps are non-uniform (resampling to a uniform display grid vs. storing adaptive steps), and the interpolation contract frameAt relies on.
• API boundary: what changes (if any) leak into the SimulationResult/Trajectory contract, and how to keep model/solver/UI separation intact (docs/model-contract.md extension points).

Outcome

A short written recommendation (ADR) — adopt, defer, or reject — with measurements. No implementation in this issue.