Widen UJacobianWrapper.p for nested ForwardDiff through Rosenbrock (#3381)

[ChrisRackauckas-Claude]

Fix for #3381. Revives the approach from the (closed) #3389 — widen UJacobianWrapper.p once inside jacobian! in OrdinaryDiffEqDifferentiation, before DI.jacobian! runs, so the per-chunk hot loop is allocation-free. Supersedes #3412.

Summary

• _widen_uf_p_for_jac(f, prep) in derivative_wrappers.jl inspects the prepared ForwardDiff.JacobianConfig to recover the inner nested-Dual eltype and lifts uf.p into that type via a fresh UJacobianWrapper with convert.(inner_T, p). Runs once per jacobian! call — every chunk DI evaluates inside that call reuses the widened p.
• Fast-path dispatch (_widen_uf_p_for_jac(f, prep) = f) is a single type-stable no-op for non-nested, AutoFiniteDiff, or FWW-wrapped cases.
• Skips widening when the user function lives behind a FunctionWrappersWrapper (AutoSpecialize): DiffEqBase already precompiles the (nested_u, outer_p, t) FW slot, so the unwidened call matches; widening would yield (nested_u, nested_p, t) that matches no slot and trips AllowNonIsBits into NoFunctionWrapperFoundError.
• Adds test/nested_forwarddiff_tests.jl. The hand-rolled outer-tag case deterministically reproduces the crash pre-fix (MethodError: no method matching Float64(::Dual{...nested...})) and passes post-fix.
• Bumps OrdinaryDiffEqDifferentiation to 2.9.1.

Root cause

NonlinearSolve seeds p with Dual{NonlinearSolveTag, Float64, 2}; inside resid! the Rosenbrock solve seeds u under OrdinaryDiffEqTag. For a FullSpecialize ODEFunction, the user body multiplies p[i] * u[i] across two different Dual nesting levels. Cross-tag multiplication resolves through ForwardDiff's @generated tagcount precedence — the literal value is baked at first compile and depends on which package precompiled which tag first. That ordering can invert the nesting and produce a triple-nested Dual that cannot be stored back into du:

MethodError: no method matching Float64(::Dual{Tag{OrdinaryDiffEqTag, Dual{Tag{NonlinearSolveTag, Float64}, Float64, 2}}, Dual{...}, 2})

Lifting p on the inner solver's side normalizes both sides of p[i] * u[i] to the same nested-Dual type, so the cross-tag arithmetic never happens.

Why here, not DiffEqBase

A DiffEqBase-side change could promote the compiled FWW signature's p slot to carry the nested Dual, but it needs either an eager Vector{DualU} allocation per UJacobianWrapper call, or a lazy WidenedDualArray wrapper whose exact type parameters have to match the compiled FW slot. Neither is free, and both push the bug-class workaround into a package that otherwise does not know about OrdinaryDiffEq's Jacobian seeding. Widening once in jacobian! costs a single convert.(inner_T, p) per step and covers every chunk DI evaluates inside that step.

Test plan

• Pkg.test(\"OrdinaryDiffEqDifferentiation\") Core group passes (25 tests, including 4 new nested-ForwardDiff tests).
• Hand-rolled outer-tag test errors pre-fix and passes post-fix.
• Original MRE from ForwardDiff errors for NonlinearSolve over ODE solve #3381 runs to StalledSuccess with the fix.
• CI.

🤖 Generated with Claude Code

[AdityaPandeyCN]

@ChrisRackauckas Earlier I thought the ForwardDiff < was the root cause as tagcount is @generated and bakes values at precompile time, so cross-tag multiplication produces the wrong nesting order. A fix (if a tag's value type is already Dual, it's structurally outer) would make ordering deterministic . I opened a issue for this on ForwardDiff for discussion(JuliaDiff/ForwardDiff.jl#801 (comment)).

What do you think of this?