Tighten the compat bound: OrderedCollections

One `[compat]` entry lists several majors.

| entry | now | suggested |
| --- | --- | --- |
| `OrderedCollections` | `1, 2` | `2` |

The smallest of the sweep. CTParser 0.9.0 already tightened `ExaModels` to `0.12` and `CTBase`
to `0.29`, so this is the only leftover.

Note CTParser's test target carries `CUDA`, `MadNLP` and `MadNLPGPU` only transitively; if they
are ever declared here, the ecosystem values apply.

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