Raise LinearSolve downgrade floor to 5.4 to fix Downgrade CI

[ChrisRackauckas-Claude]

Please ignore this PR until it has been reviewed by @ChrisRackauckas.

Fixes the Downgrade / Downgrade Tests - Core job that has been red on master since 4aad487 (run 31101445388, job 92615726301).

The failure

NLLS Hessian SciML/NonlinearSolve.jl#445: Error During Test
  Got exception outside of a @test
  LoadError: UndefVarError: `issquare` not defined
  Stacktrace:
    [1] construct_linear_solver(alg::Nothing, linsolve::Nothing, A::Matrix{ForwardDiff.Dual{...}}, ...)
      @ NonlinearSolveBase lib/NonlinearSolveBase/src/linear_solve.jl:116
    [3] _forwarddiff_implicit_solve(...)
      @ NonlinearSolveBaseForwardDiffExt lib/NonlinearSolveBase/ext/NonlinearSolveBaseForwardDiffExt.jl:244
    ...
   [25] top-level scope
      @ test/Core/forward_ad_tests__item2.jl:59
ERROR: LoadError: Some tests did not pass: 1 passed, 0 failed, 1 errored, 0 broken.

(The DomainError(Inf, "cos(x) ...") and LinearAlgebra.SingularException lines earlier in the log are logged-and-recovered errors from test/Core/setup_robustnesstesting.jl:27; those test sets report Pass/Broken and are not the failure.)

Attribution

issquare appears nowhere in this repository. It is SciMLOperators.issquare, and the undefined reference is inside LinearSolve's ForwardDiff extension: in LinearSolve 5.0.0 – 5.3.0, ext/LinearSolveForwardDiffExt.jl uses bare issquare (line 75, and the assumptions = OperatorAssumptions(issquare(prob.A)) keyword defaults on its init methods) without importing it. It resolved only because the extension does using SciMLBase and SciMLBase re-exported SciMLOperators.

Two independent changes met:

1. SciMLBase 3.40.0 dropped @reexport using SciMLOperators from src/SciMLBase.jl (present in 3.37.0/3.39.1, gone in 3.40.0+), so using SciMLBase no longer brings issquare into scope.
2. LinearSolve 5.4.0 fixed the extension — Import issquare from SciMLOperators in ForwardDiff extension LinearSolve.jl#1125 "Import issquare from its owner in ForwardDiff extension" (f1908b9), released by Release 5.4.0 so the ForwardDiff extension issquare fix ships LinearSolve.jl#1131. 5.4.0 is the first 5.x with using SciMLOperators: issquare in that file.

The root Project.toml floor is LinearSolve = "5.0.1" (set in #1099), so the downgrade job pins LinearSolve to exactly 5.0.1 — a version whose ForwardDiff extension is broken against the SciMLBase the same job pins.

The trigger commit is 4aad487 ("Nonlinear preconditioning hooks", #1084), which raised SciMLBase = "3.37" → "3.43". That moved the downgrade-pinned SciMLBase from 3.37.0 (still re-exporting SciMLOperators) to 3.43.0 (not), which is exactly where the job flips from green to red:

run	commit	SciMLBase	LinearSolve	result
31044021843	9b72448	3.37.0	5.0.1	success — `NLLS Hessian ...
31100746155	4aad487	3.43.0	5.0.1	failure — UndefVarError: issquare
31101445388	4bd97b7	3.43.0	5.0.1	failure — UndefVarError: issquare

Nothing in NonlinearSolve uses issquare, so there is nothing here to import or qualify; the floor is simply wrong. Raising it to 5.4 is the minimal correct fix — the test legitimately drives dual numbers through LinearSolve.init, and only LinearSolve ≥ 5.4 supports that with a SciMLBase ≥ 3.40.

Local reproduction

Faithful reproduction of the CI job: fresh clone of master, effective skip list computed exactly as the Compute effective downgrade skip list step does (Julia stdlibs ∪ [sources] deps), then julia-actions/julia-downgrade-compat@v2's downgrade.jl run with the same arguments (mode=deps, julia_version=lts, no_promote=Mooncake) on Julia 1.10.11.

Resolved manifest before the fix — identical to CI:

LinearSolve "5.0.1"
SciMLBase "3.43.0"
SciMLOperators "1.25.1"
ForwardDiff "1.0.1"

Before (master, downgraded):

NLLS Hessian SciML/NonlinearSolve.jl#445: Error During Test at SafeTestsets.jl:30
  Got exception outside of a @test
  LoadError: UndefVarError: `issquare` not defined
  Stacktrace:
    [1] construct_linear_solver(alg::Nothing, linsolve::Nothing, A::Matrix{ForwardDiff.Dual{...}}, ...)
      @ NonlinearSolveBase .../lib/NonlinearSolveBase/src/linear_solve.jl:116
  ...
  in expression starting at .../test/Core/forward_ad_tests__item2.jl:59
Test Summary:                            | Pass  Error  Total   Time
NLLS Hessian SciML/NonlinearSolve.jl#445 |    1      1      2  30.1s
ERROR: Some tests did not pass: 1 passed, 0 failed, 1 errored, 0 broken.

After this change, the same downgrade resolve yields LinearSolve "5.4.0" (SciMLBase/SciMLOperators/ForwardDiff unchanged) and:

Test Summary:                            | Pass  Total   Time
NLLS Hessian SciML/NonlinearSolve.jl#445 |   10     10  59.0s

The full GROUP=Core suite then passes on the downgraded manifest (the Pkg.test env is locked at LinearSolve v5.4.0 / SciMLBase v3.43.0), 79 test sets, no failures or errors:

Test Summary:                            | Pass  Total   Time
NLLS Hessian SciML/NonlinearSolve.jl#445 |   10     10  54.7s
...
     Testing NonlinearSolve tests passed

The ordinary, non-downgraded GROUP=Core run (LinearSolve v5.5.0, Julia 1.10.11) is unaffected — same 79 test sets, no failures or errors:

Test Summary:                            | Pass  Total   Time
NLLS Hessian SciML/NonlinearSolve.jl#445 |   10     10  49.9s
...
     Testing NonlinearSolve tests passed

No .jl files are touched, so Runic is a no-op here.

Notes

• Sublibrary downgrade (DowngradeSublibraries) is green on master; lib/*/Project.toml LinearSolve floors are untouched, so this does not collide with Fix the QA and Spell Check checks left red by the preconditioning hooks #1141/Let postcondition correctors declare the coordinates they act in (bounded problems) #1142 on lib/NonlinearSolveBase/Project.toml.
• Version bumped 4.25.0 → 4.25.1. Let postcondition correctors declare the coordinates they act in (bounded problems) #1142 also bumps the umbrella to 4.26.0; whichever lands second needs a trivial rebase of that one line.

🤖 Generated with Claude Code

https://claude.ai/code/session_01B9GHoo4pFa3DU9yhyTkevL

[ChrisRackauckas]

Closing as already landed.

This PR raised LinearSolve to "5.4" and bumped the version 4.25.0 → 4.25.1. Master already carries LinearSolve = "5.4", so the substantive change is in, and master is now at 4.27.0 — merging this branch would take the version backwards.

The branch has also diverged far enough that its diff against master is mostly a revert of newer work rather than its own change.

[ChrisRackauckas]

Closing as already landed.

This PR raised LinearSolve to "5.4" and bumped the version 4.25.0 → 4.25.1. Master already carries LinearSolve = "5.4", so the substantive change is in, and master is now at 4.27.0 — merging this branch would take the version backwards.

The branch has also diverged far enough that its diff against master is mostly a revert of newer work rather than its own change.