Tighten the compat bounds: JET and OrderedCollections

Two `[compat]` entries list several majors.

| entry | now | suggested |
| --- | --- | --- |
| `JET` | `0.9, 0.11, 0.12` | `0.12` |
| `OrderedCollections` | `1, 2` | `2` |

No GPU stack here, so no interaction with the `CUDSS` trap. Included for completeness — the
ecosystem sweep should leave no repository behind.

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