docs(deps): record why cadquery-ocp stays unbounded

[CameronBrooks11]

Closes the loose end #386 left under "Note, not the cause": [cadquery]
declares cadquery-ocp>=7.8, the only unbounded pin of the three.

Conclusion: no bound should be added. This PR is a comment only — the
resolution is byte-identical before and after.

The pin's specifier is inert

Measured, uv 0.11.12, uv pip install --dry-run --no-config -e '.[cadquery]' pytest:

the extra says	resolves to
cadquery-ocp>=7.8 (as declared)	cadquery-ocp==7.9.3.1.1	py3.12 and py3.13
cadquery-ocp>=7.8,<8	cadquery-ocp==7.9.3.1.1	identical
requirement deleted outright	cadquery-ocp==7.9.3.1.1	identical

cadquery depends on cadquery-ocp directly, so naming it here adds no package,
and the bounds add no constraint. Read from the published metadata rather than
restated:

• cadquery 2.8.0 → cadquery-ocp<8.0,>=7.9.3.1
• build123d 0.11.1 → cadquery-ocp-novtk<8.0,>=7.9

That <8.0 is what holds cadquery-ocp 8.0.1.0.0 (uploaded
2026-09-05T11:26:52Z) out of the solve. CadQuery is the thing compiled
against OCP, so its cap tracks the real invariant — which is not "OCP < 8" but
"the OCP CadQuery was built for". We cannot express the latter; CadQuery already
does.

A duplicate cap is not free, and it fails silently

The scenario #386 raises is "if the transitive cap ever loosened". But the cap
loosens precisely when CadQuery declares OCP 8 safe — and cadquery>=2.8,<3
admits that release. A hardcoded <8 would then constrain something we have no
evidence about, and it would not error. Reproduced on py3.12:

$ uv pip install --dry-run --no-config 'cadquery>=2.6,<3'
Resolved 44 packages in 27ms
 + cadquery==2.8.0
 + cadquery-ocp==7.9.3.1.1

$ uv pip install --dry-run --no-config 'cadquery>=2.6,<3' 'cadquery-ocp>=7.8,<7.9'
Resolved 41 packages in 154ms
 + cadquery==2.7.0
 + cadquery-ocp==7.8.1.1.post1

A stale OCP cap with an older CadQuery still in range silently backtracks the
engine and exits 0. No warning, no diagnostic. That is this project's own
thesis violated in its packaging metadata, and it is what a <8 written today
buys us the day CadQuery moves major.

(On py3.13 the same pair errors instead, because the older OCP has no cp313
wheels. The silent path is the one that matters: requires-python = ">=3.12"
and CI runs 3.12.)

And it would not have prevented #386

#386's failure was OCP 8 installed over a CadQuery built for 7.9, by
uv pip install --no-deps --reinstall-package cadquery-ocp cadquery-ocp.
--no-deps reads no requirement in pyproject.toml at all. The fix was #387's,
in the justfile, and it is the right one.

Gate

• just check — clean (ruff format --check, gen_docs --check, ruff check, pyright 0 errors)
• just test — 1378 passed in 106.72s
• just test-cadquery-only — 1133 passed, 236 skipped in 68.49s

Refs #386, #387.