Wrap Jacobian with both dense and sparse FunctionWrapper signatures

[ChrisRackauckas-Claude]

Summary

• When an ODEFunction has a sparse sparsity pattern (f.sparsity isa AbstractMatrix with non-dense type) but no jac_prototype, the solver's build_J_W may create a SparseMatrixCSC J from the sparsity pattern (when using AutoSparse).
• Previously, promote_f only wrapped the Jacobian with a dense Matrix{Float64} signature in the FunctionWrappersWrapper, causing "No matching function wrapper was found!" at solve time.
• This PR detects non-dense sparsity patterns and creates a FunctionWrappersWrapper with both dense and sparse matrix signatures, so the Jacobian call works regardless of which matrix type the solver allocates.

Context

This fixes a failure in ModelingToolkit.jl tests when using AutoSpecialize (the new default) with jac=true, sparsity=true and an implicit solver like Rodas5(). See: SciML/ModelingToolkit.jl#4335

The root cause is that OrdinaryDiffEqDifferentiation's build_J_W creates a sparse J from the sparsity pattern when alg_autodiff(alg) isa AutoSparse, even when jac_prototype is nothing. The FunctionWrapper was only registered for the dense (Matrix{Float64}, Vector{Float64}, Vector{Float64}, Float64) signature, so the call with SparseMatrixCSC failed.

Test plan

• Reproduced the "No matching function wrapper" error with jac=true, sparsity=true, Rodas5() on AutoSpecialize ODEProblem
• Verified the fix resolves the error
• Verified @inferred remake and @inferred solve still pass
• Verified prob1 (no jac) and prob2 (jac, no sparsity) still work

🤖 Generated with Claude Code