Force dense=false for SDE/RODE solutions in InterpolationData

[ChrisRackauckas-Claude]

Summary

SDE/RODE solvers never populate derivative stages (ks) because RODESolution has no .k field (_has_ks returns false, so save_dense_at_t! is a no-op). When a user passes dense=true to solve(), the InterpolationData was created with dense=true and empty ks, causing BoundsError in ode_interpolation! when it tries ks[i] for high-order interpolation.

Fix: Force dense=false when W !== nothing (SDE/RODE path) in _ode_init, right before InterpolationData construction. This makes ode_interpolation use linear_interpolant instead.

This fixes the BoundsError: attempt to access 0-element Vector{Vector{Vector{Float64}}} at index [50001] seen in SciMLSensitivity.jl's RODE InterpolatingAdjoint tests (SciML/SciMLSensitivity.jl#1398).

Test plan

• Existing SDE/RODE tests pass (they already default to dense=false)
• SciMLSensitivity RODE InterpolatingAdjoint tests pass (currently crash with BoundsError)

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Root cause of the Rodas3/ROS34PW3 interpolation bug

The consolidation PR (#3102) added a Hermite fallback in _ode_addsteps! for methods with empty H that computes:

k₁ = dt*f₀ - (u - uprev)
k₂ = 2*(u - uprev) - dt*(f₀ + f₁)

But the Hermite interpolation in generic_dense.jl expects k[1] = f₀ and k[2] = f₁ (raw derivative values), per the standard formula:

u(θ) = (1-θ)*y₀ + θ*y₁ + θ*(θ-1)*((1-2θ)*(y₁-y₀) + (θ-1)*dt*k[1] + θ*dt*k[2])

The fallback stored wrong coefficients, producing wildly inaccurate interpolation (e.g. u(0.15) = 3.97 vs correct 3.28). This caused wrong saveat values → wrong loss → wrong gradients in SciMLSensitivity tests.

Fix: Remove the incorrect Hermite fallback entirely. Methods with empty H fall through to the generic _ode_addsteps! in generic_dense.jl which correctly stores f₀ and f₁.