chore: tighten compat bounds to the newest that resolves (Phase F)

[ocots]

Summary

Seven [compat] entries listed two versions each, though every one already resolves to the
newer of the two on a free resolve — the older lane is a fallback nobody's CI exercises.
Motivated by MadNLPGPU = "0.8, 0.10": up to 0.8, CUDSS was a hard dependency and the GPU
extension armed by accident; from 0.9 it's weak and must be loaded explicitly, so keeping both
in range meant the documentation had to describe two different worlds for the same package.
Decided in decisions.md §1.

entry	before	after
CUDA	"5, 6"	"6"
CUDSS	"0.6, 0.7, 0.8"	"0.7" — not "0.8", see below
DiffEqBase	"6, 7"	"7"
ForwardDiff	"0.10, 1"	"1"
MadNLP	"0.9, 0.10"	"0.10"
MadNLPGPU	"0.8, 0.10"	"0.10"
OrdinaryDiffEq	"6, 7"	"7"

docs/Project.toml mirrors the five of these it carries (no CUDSS, no DiffEqBase entry
there).

Why CUDSS tightens to 0.7, not 0.8, specifically here

Traced the mechanism precisely: CUDSS itself declares no LinearSolve compat at all — the
constraint runs the other way. LinearSolve carries a weak-compat ceiling on CUDSS
(LinearSolve/WeakCompat.toml: ["3.80 - 5"] CUDSS = "0.7"), and this repository's
NonlinearSolve 4 pulls in a LinearSolve inside that exact bracket. CTSolvers/CTDirect
don't depend on NonlinearSolve, so they aren't capped the same way and can (and do) go to
CUDSS = "0.8".

Compatibility

No behaviour change — every bound tightens onto the version already being resolved.
No public API change.

Verification

• Both environments resolve cleanly. The 7 targets land where expected: CUDA 6.2.0/6.3.1,
  CUDSS 0.7.0, DiffEqBase 7.20.0, ForwardDiff 1.4.5, MadNLP 0.10.1, MadNLPGPU 0.10.2,
  OrdinaryDiffEq 7.8.1.
• Full test suite: 2246 pass, 0 fail, 2 broken (the two deliberate GPU skips) — identical
  to before the tightening.
• Docs build clean; unresolved @ref unchanged at 6.
• docs/src/assets/{Manifest,Project}.toml regenerated per the standing rule
  (decisions.md §2 / F15): whenever a compat bound moves, the tracked snapshot is refreshed
  in the same PR. Confirmed the OptimalControl self-entry docs: remove the seven passages three upstream fixes made false (Phase G) #899 removed stays removed — this
  PR does not reintroduce it.

Out of scope

• Mirroring these bounds in CTSolvers, CTParser, CTFlows — a separate, ecosystem-wide follow-up.
• Everything else already covered by .reports/campaign/F-compat-tighten.md.

🤖 Generated with Claude Code