Downgrade CI: raise SciMLBase compat floor to 2.146

[ChrisRackauckas-Claude]

Problem

The Downgrade CI job on main is red with an unsatisfiable package resolution. The downgrade workflow pins each direct dependency to its compat floor; with SciMLBase = "2.49, 3.1" it pins SciMLBase to 2.49.0. At that floor, the test environment's solver stack (OrdinaryDiffEq / OrdinaryDiffEqSDIRK / ModelingToolkit / MethodOfLines, brought in via test/Project.toml) can only resolve to versions on the FastBroadcast 0.3 line, while RecursiveArrayTools (dragged to 3.54 by the SciMLBase dependency graph) requires FastBroadcast 1.3 — leaving no installable FastBroadcast version:

Unsatisfiable requirements detected for package FastBroadcast [7034ab61]:
 ├─restricted by ... OrdinaryDiffEq ... to versions: 0.2.0-0.3.5
 └─restricted by ... RecursiveArrayTools 3.54.0 ... to versions: 1.3.0-1.3.2 — no versions left

Root cause

The SciML stack switches from FastBroadcast 0.3 to 1.3 at OrdinaryDiffEqCore 3.26, which requires SciMLBase >= 2.146. Any SciMLBase floor below 2.146 forces the resolver onto the old FastBroadcast 0.3 line, which is incompatible with the modern RecursiveArrayTools that the rest of the graph pulls in.

Fix

Raise the SciMLBase compat floor from 2.49 to 2.146. The package source only uses long-stable SciMLBase API (ODEProblem / ODEFunction / CallbackSet / DiscreteCallback / AutoSpecialize), so this is purely a downgrade-CI accommodation and does not restrict real functionality; the 3.x line stays supported via the existing 3.1 range entry. This continues the same pattern as #87 (which raised the floor 2.0 → 2.49).

Local verification (Julia 1.10 / lts)

Reproduced the downgrade resolution failure locally at the old floor, then confirmed it resolves at 2.146 to a single internally consistent FastBroadcast-1.3 stack:

SciMLBase = 2.146.0
OrdinaryDiffEq = 6.111.0
OrdinaryDiffEqSDIRK = 1.14.0
RecursiveArrayTools = 3.54.0
FastBroadcast = 1.3.2

Pkg.test(; force_latest_compatible_version=false, allow_reresolve=false) gets past resolution (the failing step) and into the test run with this floor. On the PR branch's own CI, Downgrade Tests is now green.

Remaining red checks are NOT in-repo bugs

The repo's other red checks on main / this PR are infrastructure, not source/dependency bugs, and are out of scope for this code change:

• tests / Core (julia 1), tests / Core (julia pre), tests / QA (julia 1) — self-hosted-runner lost-communication flakes, not test failures. In each failing job, every step is green through Set test group env (GROUP) (so checkout, setup-julia, and julia-buildpkg — i.e. resolution + precompilation — all succeeded), and then the Run tests … step and every step after it report a null conclusion (the runner died mid-step; a real test failure would record the test step as failure with the coverage steps still resolving). All three ran on self-hosted-…-runner-* boxes. Verified locally that the groups genuinely pass on the affected versions:

  • Core on Julia 1.12 (latest stack: SciMLBase 3.21.0, ModelingToolkit 11.28.0, OrdinaryDiffEq 7.0.1, MethodOfLines 0.11.12): all 9 files green (boundary_conditions 17/17, dirichlet_source 2/2, explicit_imports 2/2, geometry 5/5, heat 2/2, ode_problem 13/13, porous_medium 3/3, problem 24/24, robin_diffusion 2/2), EXIT=0.
  • QA on Julia 1.11 (JET 0.9.20) and Julia 1.12 (JET 0.11.4): 7 pass / 2 broken both times — the 2 broken are the pre-existing @test_broken placeholders for QA: Aqua/JET findings marked @test_broken pending fix #84 (Aqua deps_compat + JET), not regressions.

  These clear on a CI re-run that lands on a healthy runner; no source change is warranted.

• Documentation (on main only) — the docs build succeeds; deploydocs fails at git fetch upstream (exit 128, "DOCUMENTER_KEY … not correctly set up"), i.e. a missing/invalid gh-pages deploy key (repo secret). The deploy step only runs on push to main, which is why this PR's Documentation check is green (PRs build but do not deploy). Fixing it requires setting the DOCUMENTER_KEY secret on the repo, not a code change.

---

Please ignore until reviewed by @ChrisRackauckas