Re-enable downgrade CI with corrected [compat] lower bounds

[ChrisRackauckas-Claude]

Re-enables the downgrade CI workflow (disabled via if: false in #105) and raises the [compat] lower bounds that were too low to resolve and pass on the Julia 1.10 downgrade environment.

Floor bumps (old → new lower bound)

Package	Old	New	Reason
DifferentiationInterface	0.6, 0.7	0.7.18	0.6 range dropped; test deps need 0.7.x
ForwardDiff	0.10.36, 1	1.1	0.10 range dropped; PreallocationTools 1.x needs FD ≥ 1.1
JET	0.8, …	0.8.22, …	0.8.0 incompatible with julia 1.10
ModelingToolkitBase	1.6.2	1.8.0	first version allowing PreallocationTools 1.x; needs Symbolics ≥ 7.8
ModelingToolkitStandardLibrary	2.24	2.27	Symbolics 7 + PreallocationTools 1.x
OptimizationBase	4.0.2, 5	4.1, 5	MTK 11.7.1 needs ≥ 4.1
OptimizationOptimisers	0.3	0.3.14	uses OptimizationBase 4, compatible with Lux 1.14's Optimisers 0.4.6
OrdinaryDiffEqVerner	1, 2	1.10, 2	needs OrdinaryDiffEqCore 3 to match SciMLSensitivity
SciMLSensitivity	7.72	7.93	needs ForwardDiff 1 + PreallocationTools 1.x + OrdinaryDiffEqCore 3
SciMLStructures	1.1.0	1.10	test env forces ≥ 1.10
SymbolicIndexingInterface	0.3.41	0.3.43	SCCNonlinearSolve (via MTK 11.7.1) needs ≥ 0.3.43
Symbolics	7	7.8	ModelingToolkitBase 1.8 + MTKStdLib 2.27
Zygote	0.6.73, 0.7	0.7.5	0.6 range dropped; needs SciMLBase ≥ 2.135 (MTK 11.7.1) and ForwardDiff 1

Local downgrade suite: PASS

Ran Pkg.test() on Julia 1.10.11 with every non-stdlib [compat] dep pinned to its new declared floor. Resolved at the floors (ForwardDiff 1.1.0, SciMLSensitivity 7.93.0, OrdinaryDiffEqVerner 1.10.0, Symbolics 7.8.0, ModelingToolkitBase 1.8.0, PreallocationTools 1.2.0) and the suite passed:

Test Summary:                       | Pass  Broken  Total
ModelingToolkitNeuralNets.jl        |  106       2    108

The 2 Broken are the pre-existing @test_broken gradient comparisons in test/lotka_volterra.jl (not introduced here).

Ignore until reviewed by @ChrisRackauckas.

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Updated the Downgrade.yml caller to the strict SciML default allow-reresolve: false (reverting the earlier true). This makes the downgrade job rigorous: julia-downgrade-compat pins the direct [deps] to their declared floors and forces transitive deps to LATEST, and Pkg.test must instantiate that exact set with no reconciliation.

Local verification (Julia 1.10, GROUP=Core, isolated depot, deps-mode reproduced exactly): pinned only the [deps] compat to floors (ComponentArrays 0.15.28, IntervalSets 0.7.10, Lux 1.14, LuxCore 1.2, ModelingToolkitBase 1.8.0, Symbolics 7.8; transitive floated to latest) and ran Pkg.test(; allow_reresolve=false). The strict set resolved + instantiated + fully precompiled the entire stack (SciMLSensitivity, ModelingToolkit 11, Lux, Enzyme, Zygote, NonlinearSolve 4.x, RecursiveArrayTools, ADTypes, ForwardDiff 1.x, etc.) with no Unsatisfiable error — confirming the existing [deps] floors are strict-consistent with the latest transitive ecosystem at allow-reresolve: false. No floor raises were needed.

Honesty note: the test scripts then ran for 30-50+ min at 100% CPU (the lotka_volterra.jl UDE does Adam 10k + LBFGS 5k iterations, twice), but on this shared machine the run was terminated externally (resource pressure) before the suite printed its final summary on two attempts. I therefore did not observe a printed Testing ... tests passed, so I am not claiming a test-suite PASS — only that the strict resolution/instantiate/precompile (the part allow-reresolve actually governs) succeeded cleanly. CI will provide the authoritative end-to-end strict result.

Ignore until reviewed by @ChrisRackauckas.

🤖 Generated with Claude Code

[ChrisRackauckas-Claude]

Pushed a follow-up commit removing the now-invalid allow-reresolve: input from Downgrade.yml. The reusable SciML/.github downgrade.yml workflow is being changed to always use allow_reresolve: false and to drop the allow-reresolve workflow_call input entirely (see SciML/.github PR). Once that .github PR merges and @v1 is retagged, any caller still passing allow-reresolve: would error with an invalid-input failure, so this line must go. Behavior is unchanged (it was already strict/false here).