Tighten the compat bounds: ForwardDiff and JET

Two `[compat]` entries list several majors.

| entry | now | suggested |
| --- | --- | --- |
| `ForwardDiff` | `0.10, 1` | `1` |
| `JET` | `0.9, 0.11, 0.12` | `0.12` |

CTBase sits under everything, so its `ForwardDiff` bound is the one that would keep `0.10`
reachable for the whole ecosystem even after the leaves tighten. Worth doing first, or at least
not last.

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