Downgrade: raise OrdinaryDiffEqNonlinearSolve floor to 1.15

[ChrisRackauckas-Claude]

Please ignore this PR until reviewed by @ChrisRackauckas.

Problem

The Downgrade (lts) lane fails at precompile:

MethodError: no method matching init(::NonlinearProblem, ::NonlinearSolveFirstOrder.GeneralizedFirstOrderAlgorithm; abstol, verbose)

(seen reding OrdinaryDiffEqSDIRK/OrdinaryDiffEqNonlinearSolve/NonlinearSolve precompilation).

Root cause

OrdinaryDiffEqNonlinearSolve's compat floor of "1" lets the downgrade resolver pick 1.14.1, which pulls NonlinearSolve 4.10.0. NonlinearSolve 4.10's loose compat (NonlinearSolveBase = "1.4.0 - 1", NonlinearSolveFirstOrder = "1.2.0 - 1") permits the internally inconsistent pair:

• NonlinearSolveFirstOrder 1.7.0 + NonlinearSolveBase 1.14.0

The init(::AbstractNonlinearProblem, ::AbstractNonlinearSolveAlgorithm) method that NonlinearSolveFirstOrder relies on only exists from NonlinearSolveBase 1.15.0 onward — NonlinearSolveFirstOrder 1.8 bumped its own NonlinearSolveBase floor to 1.15.0 for exactly this reason. With the downgrade-resolved NonlinearSolveBase 1.14.0, that method is absent, so precompile dies.

Fix

Raise the floor to OrdinaryDiffEqNonlinearSolve = "1.15, 2". ODENLS 1.15 requires NonlinearSolve "4.12.0 - 4" → NonlinearSolveBase "2", which eliminates the broken combination. OrdinaryDiffEqNonlinearSolve is a test-only dep (used solely for NLNewton in test/isothermal_compressible.jl), and NLNewton is stable across the bumped range.

Verification

Ran the real julia-actions/julia-downgrade-compat@v2 action (mode=deps, julia=lts) against the patched Project.toml on Julia 1.10.11, then instantiated and precompiled the resulting manifest:

• Resolved a consistent set: OrdinaryDiffEqNonlinearSolve 1.15.0, NonlinearSolve 4.12.0, NonlinearSolveBase 2.2.0, NonlinearSolveFirstOrder 1.11.1.
• Full test environment (incl. ModelingToolkitStandardLibrary + the OrdinaryDiffEq/NonlinearSolve stack) precompiled cleanly — the MethodError is gone.

Note / out of scope

This fixes the precompile blocker on the Downgrade lane. The Downgrade.yml comment about being "expected RED until the fntype regression (#458/#452) is resolved" refers to Core test failures introduced by newer ModelingToolkit (11.25+). Under downgrade the resolver pins MTK to its floor (11.0.0), which predates that regression, so those failures should not trigger here — but this PR is scoped to the NonlinearSolve precompile floor and does not attempt to address the fntype-regression tracking items.

🤖 Generated with Claude Code