Restore SciMLBase 3.39 compatibility for owner imports

[ChrisRackauckas-Claude]

Ignore until reviewed by @ChrisRackauckas.

Summary

• restore the SciMLBase compatibility floor from 3.40 to 3.39 for DiffEqBase, OrdinaryDiffEqCore, OrdinaryDiffEqDifferentiation, and OrdinaryDiffEqNonlinearSolve
• import MatrixOperator and update_coefficients! from their declaring public package, SciMLOperators, in the affected tests
• declare SciMLOperators in the separate differentiation sparse-test environment

Why

The first bad commit is d78527d (#4059). It switched the tests from SciMLBase reexports to direct SciMLOperators ownership, but also raised the four SciMLBase floors to 3.40. Current General has SciMLBase 3.39.1 as its newest registered release, so a fresh checkout of OrdinaryDiffEq master cannot resolve OrdinaryDiffEqCore 4.12.

The used SciMLOperators interfaces are already public and available with SciMLBase 3.39. These source versions (DiffEqBase 7.10.0, OrdinaryDiffEqCore 4.12.0, OrdinaryDiffEqDifferentiation 3.6.0, and OrdinaryDiffEqNonlinearSolve 2.6.0) are newer than their latest registered versions and already contain the owner-import fixes. Lowering their source floors is therefore independently safe: it controls the future registration of the fixed versions and does not alter compatibility metadata for older releases.

The pending General registry PR JuliaRegistries/General#162635 separately retro-caps affected older releases before SciMLBase 3.40 becomes available. It is not yet effective and is not a prerequisite for the fixed source versions to support both SciMLBase 3.39 and 3.40.

Investigation

• reproduced the resolver failure from a fresh Julia 1.12 depot on clean master
• bisected the first failure to d78527d
• verified the parent commit resolves with registered SciMLBase 3.39.1
• tested this exact patch with registered SciMLBase 3.39.1 and local SciMLBase 3.40.1

Tests

• GROUP=Core for OrdinaryDiffEqNonlinearSolve with registered SciMLBase 3.39.1 — passed
• GROUP=Core for OrdinaryDiffEqNonlinearSolve with local SciMLBase 3.40.1 — all affected suites passed; the run then reached the independent LinearSolveForwardDiffExt issquare error described below
• GROUP=Sparse for OrdinaryDiffEqDifferentiation with registered SciMLBase 3.39.1 — 2/2 passed
• targeted Runic check on all changed Julia files
• git diff --check

The registered 3.39.1 Core run completed every testset and exited successfully. With the local SciMLBase 3.40.1 checkout, Newton, sparse DAE initialization, linear solver, split ODE, mass matrix, W-operator, DAE initialization, and CheckInit all passed. Nested AD then stopped with UndefVarError: issquare not defined in LinearSolveForwardDiffExt (1 pass, 1 error). The same Nested AD suite passed 5/5 against registered SciMLBase 3.39.1, and the error is in LinearSolve's ForwardDiff extension after the SciMLBase reexport removal, not in this patch.

Whole-tree Runic currently also reports formatting failures introduced on clean master by the independent DISCO merge. That clean-master regression is handled separately by #4064 and is not included here.

[ChrisRackauckas-Claude]

Final hosted-CI classification on exact head b20dd6753e: 238 checks succeeded, 3 were skipped, and 33 failed.

The compatibility/owner-import change itself remains locally verified on both sides of the boundary: the full OrdinaryDiffEqNonlinearSolve Core group passed with registered SciMLBase 3.39.1; its local SciMLBase 3.40.1 control passed the affected suites before reaching an independent LinearSolve extension error.

Focused follow-ups already isolated:

• Runic reports only the clean-master DISCO formatting regression: Run Runic on the disco-optimizations files #4064.
• All five SciMLSensitivity jobs stop during resolution at its SciMLBase 3.40 source floor versus registered 3.39.1: Allow SciMLBase before 3.40 is registered SciMLSensitivity.jl#1575.
• All three root Downstream lanes reach the same unitful-time DISCO checkpoint error. It reproduces on clean master, bisects to 408a7a30fe, and is fixed separately by Initialize the DISCO checkpoint from the time value #4069. The Restore SciMLBase 3.39 compatibility for owner imports #4066 + Initialize the DISCO checkpoint from the time value #4069 local official Downstream run passed time derivatives 202/202 and DynamicQuantities/Measurements 6/6.
• The local SciMLBase 3.40.1 Nested-AD control reaches LinearSolve's stale issquare ownership assumption. The focused owner import and split-dual regression are in Import issquare from SciMLOperators in ForwardDiff extension LinearSolve.jl#1125; exact local OrdinaryDiffEq checks passed 4/4 and 1/1.
• Direct Julia 1.10 root testing also mixed local tests with registered sibling sublibraries because Julia 1.10 does not honor root [sources]; the public develop_sources! harness fix is Develop local sources in Julia 1.10 root tests #4068. Exact Integrators_I passed on Julia 1.10 and 1.12 (Step Limiter 254/254, DISCO 28/28).

The other failures are independent and are not being folded into this compatibility PR:

• PositiveIntegrators cannot resolve its LinearSolve 3-only bound against the current OrdinaryDiffEq 5.1+ requirement. No external-repository write has been made.
• ProbNumDiffEq's test environment pins JET 0.11 while the OrdinaryDiffEq downstream workflow runs Julia 1.10, which supports only older JET versions.
• DelayDiffEq Interface accesses newly required DISCO state absent from DDEIntegrator; a clean-master reproduction/bisect/fix is active separately.
• DiffEqBase Downstream tries to initialize a Diagonal Jacobian prototype through dense fill!; a clean-master structured-storage investigation is active separately.
• FunctionMap QA reaches non-public Base.structdiff; Delay, Default, Rosenbrock, and StochasticDiffEq QA expose separate public-owner/API issues; LowOrderRK and StochasticHighOrder expose missing public docstrings; StabilizedRK reports stale imports; several stochastic packages also expose duplicate-binding/doc-scanner and stale-broken-marker/JET issues. These require focused API/QA fixes, not new ignore lists.
• Numerical checks needing real investigation (not tolerance loosening) are the root AD callback assertions, three ModelingToolkit symbolic-event crossing assertions, the OrdinaryDiffEqNonlinearSolve ModelingToolkit assertion, and the Hairer4 GPU DAE mismatch. The same Hairer4 mismatch appears in two earlier hosted clean-master GPU runs; this machine has no GPU, so no local-GPU success claim is being made.
• DiffEqDevTools Core was an infrastructure failure: GitHub's annotation says the self-hosted runner lost communication. DiffEqDevTools QA and TaylorSeries QA report Aqua persistent-task subprocess failures and still need local reproduction.

No CI-only workaround, skipped test, tolerance change, or unrelated dependency edit is included in #4066.

[ChrisRackauckas-Claude]

Rebase/final local-validation checkpoint for head 661bd35c64:

• rebased the focused commit onto current upstream b22e2e58b2; git range-diff reports the old and new commits as exact (=);
• reran the official GROUP=OrdinaryDiffEqNonlinearSolve harness on Julia 1.12 with registered SciMLBase 3.39.1;
• the first run's one-hour shell wrapper terminated during nested AD without an assertion failure, so I repeated the exact group with a three-hour shell budget;
• the retry exited 0 after 3,040.34 seconds with OrdinaryDiffEqNonlinearSolve tests passed and OrdinaryDiffEq tests passed.

Passed testsets include Newton 6/6, sparse DAE init 27/27, nonlinear solver 44/44, linear solver 113/113, split ODE 10/10, mass matrix 225 pass/42 existing broken, W-operator 18/18, DAE init 19/19, CheckInit 4/4, nested AD 5/5, Jacobian reuse 11/11, homotopy 25/25, default homotopy init 16/16, sparse Jacobian 10/10, matrix-free W-operator 14/14, smoothed estimate 10/10, and stats 24/24.

Immediately before pushing I fetched upstream and the fork. Upstream remained b22e2e58b2; the remote branch remained our prior b20dd6753e commit with no contributor commits. I therefore updated it using an exact-SHA --force-with-lease, and verified the remote now points to 661bd35c64a3bdf937faa8b00748a2aa2063a798.

[ChrisRackauckas-Claude]

Terminal current-head CI audit for exact head 661bd35c64a3bdf937faa8b00748a2aa2063a798:

• 241 succeeded, 30 failed, 3 skipped, 0 pending.
• The changed nonlinear-solve coverage passes locally with the repository harness: GROUP=OrdinaryDiffEqNonlinearSolve julia +1.12 --project -e 'using Pkg; Pkg.test()'. The completed retry took 3040.339 s and passed Newton, sparse DAE, linear/nonlinear solver, mass-matrix, DAE initialization, nested-AD, Jacobian-reuse, homotopy, default-homotopy-init, sparse-Jacobian, matrix-free-W, smoothed-estimate, and stats coverage. (The first 3600 s run reached nested AD without an assertion failure; the required higher-budget retry completed.)
• The 30 terminal failures are outside this patch and classify as:
  • 1 Runic prerequisite: Run Runic on the disco-optimizations files #4064.
  • 5 SciMLSensitivity resolver failures: Allow SciMLBase before 3.40 is registered SciMLSensitivity.jl#1575 / General still resolving SciMLBase 3.39.1.
  • 1 ModelingToolkit InterfaceI symbolic-event tolerance failure.
  • 1 ProbNum JET 0.11 / Julia 1.10 incompatibility.
  • 1 PositiveIntegrators LinearSolve resolver failure.
  • 1 DiffEqDevTools downgrade log/infrastructure failure.
  • 1 root AD event-gradient failure: Keep callback controller resets opt-in #4075.
  • 1 DelayDiffEq missing is_disco_step: Add discontinuity-controller state to DDE integrators #4071.
  • 1 DiffEqBase downstream diagonal storage failure: Preserve structured Jacobian cache storage during initialization #4072.
  • 1 root GPU Hairer4 CSC/diagonal CUDA mismatch (also observed independently of this patch).
  • 2 DiffEqDevTools runner/persistent-task infrastructure failures.
  • 13 untouched sublibrary QA jobs (Default, FunctionMap, LowOrderRK, Rosenbrock, StabilizedRK, TaylorSeries, and seven StochasticDiffEq groups).
  • 1 NonlinearSolve/ModelingToolkit NLStep comparison: Align NLStep TRBDF2 parity test estimator #4077.

The branch is clean, matches the remote head exactly, and remains mergeable. This audit does not treat unrelated/prerequisite failures as fixed.

[ChrisRackauckas-Claude]

The ModelingToolkit Julia 1.10 downstream initialization failures seen while validating this compatibility PR are now split:

• 2 collect_vars! invalidation errors are fixed in Fix collect_vars! after late invalidation on Julia 1.10 ModelingToolkit.jl#4852 (draft, locally tested, CI pending).
• 9 DelayDiffEq.MethodOfSteps errors are the separate DEOptions resolver incompatibility tracked by Retroactively cap DelayDiffEq at OrdinaryDiffEqCore 4.8.0 JuliaRegistries/General#162781.

This keeps the collector fix out of this focused SciMLBase-floor PR.

[ChrisRackauckas-Claude]

[noblock] Exact SciMLSensitivity resolver-chain audit after JuliaRegistries/General#162820:

• SciMLSensitivity 01273953206f29c81bd99b6e3ec4ea7b265d6d98 (7.117.0) fixes SciMLBase to 3.40.0 and permits OrdinaryDiffEqCore 4.3 - 5.
• With the corrected NonlinearSolveBase 2.38 registry compat, resolution now reaches the next boundary: registered OrdinaryDiffEqCore versions end at 4.11.0, and their compatibility restricts SciMLBase to 3.0.0 - 3.39.1, so no versions remain.
• I audited the exact registered OrdinaryDiffEqCore 4.11 tree 245ef20bd01866ffe583d282980152097d8894eb (monorepo commit 42499e3f6b31a7a05ae05ceadb6608019ae02814). It imports islinear from SciMLBase. On SciMLBase 3.40, Base.ispublic(SciMLBase, :islinear) == false; the declaring public owner is SciMLOperators, where Base.ispublic(SciMLOperators, :islinear) == true.
• As a runtime control, I widened only the temporary Project compat lines for the exact registered OrdinaryDiffEqCore 4.11 / DiffEqBase 7.9 source. Both precompiled and loaded with SciMLBase 3.40.0, but only because the old private SciMLBase reexport binding still exists (SciMLBase.islinear === SciMLOperators.islinear). That is not valid public-API compatibility.

Therefore the OrdinaryDiffEqCore 4.11 cap is intentional and should not be reopened in General. The owner import is fixed in #4059/current OrdinaryDiffEqCore 4.12; this PR followed by registration of that fixed release is the correct unblock for the SciMLSensitivity endpoint.