CI: check/remove now-redundant spatialgeometry git-install step

[petercorke]

Migrated from tech-debt.md (deleted, see repo history via git log -- tech-debt.md), and updated in light of today's fix.

The old tech-debt.md entry flagged that .github/workflows/ci.yml installed the external spatialgeometry from git (pip install git+https://github.com/petercorke/spatialgeometry.git@future) in every job that also needs swift, while RTB's own pyproject.toml at the time vendored a full copy of spatialgeometry inside its own wheel (src/spatialgeometry/) -- i.e. two packages exporting the same import name, installed in sequence, with the vendored one likely clobbering the git-installed one.

As of this session, the vendoring has been removed (see the fix/unvendor-spatialgeometry PR): spatialgeometry is back to being a normal pyproject.toml dependency (currently pinned to a specific commit on SG's unreleased main, since Link.py's SceneGroup call now requires API that hasn't shipped in a PyPI release yet -- see that PR's description for the full story). That resolves the original "two copies fighting" concern, but leaves a follow-up:

• Check whether ci.yml's explicit pip install git+https://github.com/petercorke/spatialgeometry.git@future step is now fully redundant with the pyproject.toml pin (it should be -- pip install .[dev] will already pull in the pinned commit) and remove it if so. Also double check the @future branch reference itself is still meaningful -- SG's active development branch as of this session is main, not future; if future is stale/abandoned, the reference needs updating regardless of the redundancy question.
• Once spatialgeometry actually cuts a 1.4.0 (or later) PyPI release matching the API Link.py now targets, switch pyproject.toml's pin from the git+commit form back to a normal >=1.4.0 version constraint.