Tighten the compat bounds: keep only the newest major that resolves

Seven `[compat]` entries list several majors. Each resolves to the newest anyway, so the older
lanes are fallbacks nobody runs and nobody tests.

| entry | now | suggested | resolves to |
| --- | --- | --- | --- |
| `CUDA` | `5, 6` | `6` | 6.2.0 |
| `CUDSS` | `0.6, 0.7, 0.8` | `0.8` | 0.8.0 — **verified below** |
| `DiffEqBase` | `6, 7` | `7` | 7.18.2 |
| `ForwardDiff` | `0.10, 1` | `1` | — |
| `MadNLP` | `0.9, 0.10` | `0.10` | 0.10.1 |
| `MadNLPGPU` | `0.8, 0.10` | `0.10` | 0.10.2 |
| `JET` | `0.9, 0.11, 0.12` | `0.12` | — |
| `OrderedCollections` | `1, 2` | `2` | — |

Measured on CTSolvers 0.5.4, with `CUDSS` forced to 0.8 and the rest of the test target added:

```text
CUDA 6.2.0 CUDSS 0.8.0 MadNLP 0.10.1 MadNLPGPU 0.10.2
DiffEqBase 7.18.2 ExaModels 0.12.0
```

`CTSolversMadNLPGPU`, `CTSolversCUDA` and `ArrayInterfaceCUDSSExt` all precompiled. `LinearSolve`
is not in the resolved manifest at all, which is why 0.8 is reachable here and not 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.