Tighten the compat bounds: keep only the newest major #32

Three [compat] entries list several majors.

Small and self-contained — no GPU solver stack here, so no interaction with the CUDSS trap.

Why now

The ecosystem decision (2026-08-26) is to keep only the newest major where it resolves. The
trigger was MadNLPGPU = "0.8, 0.10", which spans a behaviour change: up to 0.8, CUDSS was a
hard dependency, so using MadNLPGPU armed the GPU extension by accident; from 0.9 it is a
weak dependency and must be loaded explicitly. Keeping both in range forces the
documentation to describe two worlds, and only one of them is ever resolved.

The one trap — do not harmonise CUDSS across the ecosystem

CUDSS 0.8.0 requires LinearSolve ≤ 2.28, while NonlinearSolve 4 requires
LinearSolve ≥ 3.48. So the right bound differs per repository, measured 2026-08-26:

That divergence is correct. Do not "fix" it into a single shared value.

Related

• Ecosystem plan: OptimalControl.jl/.reports/campaign/F-compat-tighten.md
• Decision record: OptimalControl.jl/.reports/campaign/decisions.md §1
• CTSolvers#216 — the GPU
  ExtensionError names MadNLPGPU when the missing trigger is CUDSS. Tightening to 0.10
  makes that message wrong 100% of the time instead of sometimes, so the two changes belong
  together.