Tighten the compat bounds: keep only the newest major

Four `[compat]` entries list several majors.

| entry | now | suggested |
| --- | --- | --- |
| `CUDA` | `5, 6` | `6` |
| `DiffEqBase` | `6, 7` | `7` |
| `ForwardDiff` | `0.10, 1` | `1` |
| `GPUArraysCore` | `0.1, 0.2` | `0.2` |

⚠️ **CTFlows is the one sibling that depends on `NonlinearSolve`.** It has no `CUDSS` entry
today, so the trap below does not bite — but if `CUDSS` is ever added here, it must be `"0.7"`,
not `"0.8"`, for the same reason it must be in OptimalControl.

## 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:

| repository | has `NonlinearSolve` | `CUDSS = "0.8"` |
| --- | --- | --- |
| CTSolvers, CTDirect | no | **resolves** — CUDA 6.2.0, MadNLPGPU 0.10.2, no LinearSolve at all |
| OptimalControl | yes (4.28.0) | **unsatisfiable** — must stay `"0.7"` |

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](https://github.com/control-toolbox/CTSolvers.jl/issues/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.