cython: add build-cython.yml for riscv64 wheels

[luhenry]

What

Adds .github/workflows/build-cython.yml to build Cython 3.3.0 riscv64 wheels and publish them to pypi.riseproject.dev.

Why

Cython ships per-interpreter compiled wheels (cp39–cp315) plus a py3-none-any fallback on PyPI, but none for riscv64. Every source build of a Cython-using package on riscv64 (protobuf, fonttools, grpcio-tools, …) compiles Cython from sdist today — a compiled riscv64 wheel removes that repeated cost.

Shape

• Build-from-checkout. Cython is self-hosting: setup.py compiles its own modules with the in-tree Cython, so no external build tool / CIBW_BEFORE_BUILD is needed. Tag 3.3.0 == package version, so no sdist/version-derivation step.
• Matrix [cp312, cp313, cp314], per-interpreter (not abi3). No cp314t: setup.py disables self-compilation under Py_GIL_DISABLED (a compiled Cython would force the GIL back on), so a free-threaded build would silently ship the pure-Python fallback. Upstream ships zero free-threaded compiled wheels.
• Wheel test asserts a core module (Cython.Compiler.Scanning) loaded from a compiled .so — guarding against a silent degrade to the mislabeled pure-Python wheel — then cythonizes + compiles + imports a .pyx to prove the wheel works as a compiler end-to-end. CIBW_TEST_REQUIRES: setuptools because the manylinux base interpreter ships neither setuptools nor distutils (dropped in 3.12), which cythonize -i needs.

Local validation (QEMU / manylinux_2_39_riscv64)

• The self-compile produces a genuine RISC-V ELF .so under QEMU: Scanners.cpython-312-riscv64-linux-gnu.so … UCB RISC-V, RVC, double-float ABI.
• The test command was validated arch-independently: it passes on a real compiled Cython wheel (full cythonize→compile→import chain) and fails with exit 1 on the py3-none-any wheel (AssertionError: expected compiled .so … (pure-Python fallback)).
• A full 20-module wheel build to completion under QEMU is impractical on the dev host (heavy emulated compile + contention); the native riscv64 CI runner does it here.

🤖 Generated with Claude Code

[threexc]

The error is coming from upstream's pyproject.toml, starting at line 31:

[tool.cibuildwheel.linux.environment]
CFLAGS = "-O3 -g0 -pipe -fPIC -DNDEBUG -march=core2 -mno-ssse3"
AR = "gcc-ar"
NM = "gcc-nm"
RANLIB = "gcc-ranlib"
PIP_BUILD_CONSTRAINT = ".github/wheel_build_constraints.txt"
PIP_CONSTRAINT = ".github/wheel_build_constraints.txt"

There are sections following it for different architectures, e.g.:

[[tool.cibuildwheel.overrides]]
select = "*aarch64"
inherit.environment = "append"
environment = {CFLAGS = "-O3 -g0 -pipe -fPIC -DNDEBUG -march=armv8-a -mtune=cortex-a72", AR = "gcc-ar", NM = "gcc-nm", RANLIB = "gcc-ranlib"}

Easiest is to add a patch for our needs, and I can take this as a task to try getting upstream.

EDIT: I went to see how we build it for qemuriscv64 in Yocto (which also builds riscv64gc packages right now). Here's what I think is the key set of flags:

-march=rv64imafdc_zicsr_zifencei -mabi=lp64d -fstack-protector-strong

[threexc]

@luhenry my bad, my suggestion to rework the triggers broke our UI experience a bit (not actually seeing the workflows running anymore). I'm going to get a revert in and improve the logic. Here is the workflow you triggered: https://github.com/riseproject-dev/python-wheels/actions/runs/32887623280