test: investigate Windows Cython dist failure

[henryiii]

🤖 AI text below 🤖

Draft — investigation only, not for merge.

The dist job on windows-latest fails for all three Cython projects (hello-cython, core-cython-hello, pen2-cython) with:

ModuleNotFoundError: No module named 'Cython'

raised when the cython.exe console script is invoked during CMake configure (via cython-cmake's FindCython.cmake for the core project, and find_package for the legacy setuptools projects). The failure is Windows-only and hits both build-backend families, so it is not the CMake policy-max bump (#79) and not scikit-build-core alone.

Between the last green main run (Jul 7) and now the Windows image is unchanged (VS 18 2026, MSVC 19.51, Python 3.12.10, CMake 4.3.4). The floated build deps are the suspects. This PR pins cython<3.2.8 in the three projects' build requirements as the first single-variable test.

• If Windows dist goes green → Cython 3.2.8's console-script behavior in the isolated build env is the culprit.
• If it stays red → rule out Cython and move the pin to uv / another dep.

[henryiii]

🤖 AI text below 🤖

Bisection update

The cython<3.2.8 pin did not fix it — cython==3.2.6 was installed and Windows dist failed with the identical ModuleNotFoundError: No module named 'Cython'. Cython version ruled out.

Comparing the last green main run (Jul 7) against the red one, holding everything else constant (CMake 4.3.4, same VS 18 2026 / MSVC 19.51 / Python 3.12.10):

	uv	cython	scikit-build-core
Jul 7 green	0.11.27	3.2.8	1.0.0
Jul 11 red	0.11.28	3.2.6/3.2.8	1.0.2

uv is the only variable common to all three failing projects — the two legacy setuptools projects don't load scikit-build-core at all, yet fail identically. This push pins uv==0.11.27 via setup-uv to confirm the 0.11.27 -> 0.11.28 regression.