Raise root LinearSolve compat floor to 5 to fix Downgrade CI

[ChrisRackauckas-Claude]

This PR should be ignored until reviewed by @ChrisRackauckas.

Problem

The "Downgrade / Downgrade Tests - Core" job (root package downgrade test) fails on master and on nearly all recent PRs. Failing master run: https://github.com/SciML/NonlinearSolve.jl/actions/runs/29706251701 (job fails ~40s in, during Pkg.test's sandbox resolve, before any test runs):

ERROR: LoadError: Unsatisfiable requirements detected for package LinearSolve [7ed4a6bd]:
 LinearSolve [7ed4a6bd] log:
 ├─possible versions are: 0.1.0-5.0.0 or uninstalled
 ├─restricted to versions 5 by NonlinearSolveQuasiNewton [9a2c21bd], leaving only versions: 5.0.0
 │ └─NonlinearSolveQuasiNewton [9a2c21bd] is fixed to version 1.14.1
 └─restricted to versions 4.3.0 by an explicit requirement — no versions left

Root cause

The Downgrade workflow min-resolves the root Project.toml at its compat floors, while the [sources] sublibraries are kept fixed as path dependencies (they are on the downgrade skip list). PR #1070 (6264446) aligned the tree: sublibraries went to LinearSolve = "5" and the root floor was raised to LinearSolve = "5" to match.

Commit 60736b5 ("Require operator-capable NonlinearSolveBase", #1079, merged 2026-07-16) reverted the root entry from LinearSolve = "5" back to LinearSolve = "4.3, 5" while bumping the NonlinearSolveBase floor. Since the in-tree NonlinearSolveBase / NonlinearSolveFirstOrder / NonlinearSolveQuasiNewton all require LinearSolve = "5", the downgrade resolution (root LinearSolve pinned at its 4.3.0 floor) became unsatisfiable. The first master Downgrade run at 60736b5 (https://github.com/SciML/NonlinearSolve.jl/actions/runs/29487978734) already fails with this exact conflict.

Fix

Raise the root floor back to LinearSolve = "5", matching the source-tree sublibraries. No version bump, following the precedent of the earlier floor-alignment PRs (#1059, #1070, #1075).

Verification

Reproduced and verified locally on Julia 1.10.11 (the workflow's LTS) in a fresh clone, emulating CI exactly: computed the effective skip list (stdlibs + all [sources] deps) as SciML/.github downgrade.yml@v1 does, ran julia-actions/julia-downgrade-compat@v2's downgrade.jl with mode=deps, then Pkg.instantiate(); Pkg.build() and

GROUP=Core julia +1.10 --project=@. -e 'import Pkg; Pkg.test(;coverage=false,
    julia_args=["--check-bounds=yes", "--compiled-modules=yes", "--depwarn=yes"],
    force_latest_compatible_version=false, allow_reresolve=false)'

• On unmodified master: min-resolve picks LinearSolve 4.3.0 and Pkg.test fails with the identical Unsatisfiable requirements detected for package LinearSolve error as CI.
• With this fix: min-resolve picks LinearSolve 5.0.0, the test sandbox resolves, and the full Core group passes — Testing NonlinearSolve tests passed, exit code 0.

The remaining test failures seen in the 2026-07-15 master Downgrade run (23 Test Problems: Broyden broken-test list) were already fixed by #1051 (74405d3), so with this floor fix the job is green again.

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Status update after the first CI round on this PR.

The LinearSolve floor fix works as intended: the Downgrade job now gets past resolution (previously it died in ~40 s with Unsatisfiable requirements detected for package LinearSolve), min-resolves LinearSolve to 5.0.0, and runs the full Core suite.

The remaining Downgrade failure is not a downgrade problem. The job now fails 5m39s in with exactly one test failure:

8: Brown almost linear function | alg #4: Test Failed at test/Core/setup_robustnesstesting.jl:25
  Expression: norm(res, Inf) ≤ ϵ
   Evaluated: 5.5 ≤ 0.001

Investigation of why this cannot be fixed by raising compat floors:

1. Identical failure at latest versions. This PR's regular tests / Core (julia 1, ubuntu-latest) job (88367640144) fails with the same single test, same residual 5.5, using the newest resolved versions of everything. A failure that occurs identically at both the minimum and the latest ends of the compat range cannot be caused by any floor.
2. Version-independent, machine-dependent. I diffed the CI Downgrade job's resolved versions (its Pkg.status output) against my local min-resolved environment: byte-identical, all 116 entries. Locally (x64 Linux, Julia 1.10.11) that exact environment passes the entire Core group (Testing NonlinearSolve tests passed). The delta is the machine (BLAS/CPU kernel dispatch), not packages.
3. Pre-existing on master. Master's own tests / Core (julia lts) job at 74405d3 (88243697971) already fails with the identical 5.5 — this PR merely unmasked the same failure inside the Downgrade job by letting it reach the test phase.

Root cause of the residual failure: 74405d3 (#1051) changed broken_tests[alg_ops[4]] from [5, 6, 8, 11] to [1, 5, 6, 11], unmarking problem 8 for Broyden(bad_broyden, true_jacobian) based on an environment where it converges. On the CI runners it deterministically lands at residual 5.5. The problem is numerically marginal and flips by hardware — note the 2026-07-15 Downgrade run failed in the opposite direction ("Unexpected Pass" on problem 8 while it was still marked broken), so neither @test nor @test_broken is stable for it across machines.

Per repo policy I am not loosening the tolerance, skipping, or re-marking the test broken in this PR. Tracking issue with the full evidence table: #1096. This PR remains the correct and complete fix for the Downgrade resolution failure; the Downgrade job will go green once #1096 is resolved (the robustness suite outcome is the only remaining failure in that job).