workflows: add build-fastuuid.yml for riscv64 manywheel builds

[luhenry]

What

Adds .github/workflows/build-fastuuid.yml to build fastuuid 0.14.0 riscv64 wheels and publish them to pypi.riseproject.dev. fastuuid ships no riscv64 wheel on public PyPI.

Relates to #290

Approach

fastuuid is a PyO3/Rust extension built with maturin, with no C native dependencies (pure-Rust: pyo3 0.26, uuid, rand). Wheels build directly from an upstream checkout via cibuildwheel on the manylinux_2_39_riscv64 image — the same shape as build-tiktoken.yml.

• Rust toolchain in-container: fastuuid carries no [tool.cibuildwheel], so rustup is installed via CIBW_BEFORE_ALL_LINUX and put on PATH via CIBW_ENVIRONMENT_LINUX. (Verified locally under QEMU: rustup provisions a native riscv64gc-unknown-linux-gnu toolchain inside the container.)
• The .cargo/config.toml in the checkout sets --cfg uuid_unstable, required to compile the uuid crate's v1/v7 features. cibuildwheel copies the whole tree in, so it's picked up automatically.
• Matrix cp312/cp313/cp314/cp314t: fastuuid is not abi3 (upstream ships per-interpreter wheels), so every Python version needs its own build.

Testing (mirrors upstream)

Each wheel is tested inside the container against the matching interpreter by running fastuuid's own pytest suite (tests/test_uuid.py + tests/test_benchmarks.py) via CIBW_TEST_COMMAND. Upstream's tox also runs black/isort, but those are dev-only lint, not wheel tests, so they're skipped. All test deps (pytest, hypothesis, pytest-benchmark, uuid7) are pure-Python wheels on public PyPI — no registry plumbing needed.

Locally validated by building the wheel with maturin on aarch64 and running the full suite: 96 passed.

Notes

• musllinux is skipped (rustup.rs has no riscv64 musl host toolchain — same reason build-tiktoken.yml skips it).
• The shared publish-wheels action dry-runs on non-main branches, so it's safe on this PR.

🤖 Generated with Claude Code

[luhenry]

✅ CI green — run 32394076456: all 4 wheel jobs (cp312/cp313/cp314/cp314t) build + test pass, publish dry-runs cleanly.

• Each wheel runs fastuuid's full pytest suite inside the riscv64 container: 96 passed per interpreter (incl. free-threaded cp314t).
• Publish matched all 4 wheels and dry-ran (not on main branch — no upload), so it's ready for the real upload on merge.

Two issues surfaced and fixed during the loop (both reinforced back into CLAUDE.md):

1. Floating uuid crate + #![deny(warnings)]. fastuuid gitignores Cargo.lock, so a fresh resolve floated uuid 1.18→1.24, which deprecated uuid::Context; deny(warnings) turned that into a hard compile error. Fixed by pinning uuid to the release version (1.18.1) before building our own sdist.
2. {project} vs {package} in the test command. Tests live in the sdist dir we pass to cibuildwheel ({package} = /project/fastuuid), not the invocation dir ({project} = /project). pytest {project}/tests → not found; fixed to {package}/tests.

[luhenry]

@justeph @threexc please have a look, thank you!

[threexc]

Same comment as @justeph on #280 - the docs tweaks should be separate to the fastuuid workflow.

More importantly, since fastuuid is built with maturin, it makes sense for us to try submitting a riscv64 build (including runner setup instructions) directly to the upstream repository first. We'd probably still need to merge this and trigger the workflow at least once until there's a new release upstream, but it'd be good to see what their position on riscv64 support is first.

@luhenry do you want to do that, or should I?

[luhenry]

@threexc please go ahead with the upstreaming. I'll separate the CLAUDE.md changes. Does the workflow file looks good? I won't change that otherwise.

[threexc]

@threexc please go ahead with the upstreaming. I'll separate the CLAUDE.md changes. Does the workflow file looks good? I won't change that otherwise.

The workflow looks good, but when peeking at the upstream version I noticed that they don't build for 3.14t yet. I was curious to see how your build for that target went, so I looked and saw this in the test step:

      + sh -c 'HYPOTHESIS_PROFILE=dev pytest -q /project/fastuuid/tests --benchmark-disable'
  ........................................................................ [ 75%]
  ........................                                                 [100%]
  =============================== warnings summary ===============================
  <frozen importlib._bootstrap>:491
    <frozen importlib._bootstrap>:491: RuntimeWarning: The global interpreter lock (GIL) has been enabled to load module 'fastuuid.fastuuid', which has not declared that it can run safely without the GIL. To override this behavior and keep the GIL disabled (at your own risk), run with PYTHON_GIL=0 or -Xgil=0.

Looking into it.

[luhenry]

@threexc please go ahead with the upstreaming. I'll separate the CLAUDE.md changes. Does the workflow file looks good? I won't change that otherwise.

The workflow looks good, but when peeking at the upstream version I noticed that they don't build for 3.14t yet.

I'll remove the build then.

[threexc]

@threexc please go ahead with the upstreaming. I'll separate the CLAUDE.md changes. Does the workflow file looks good? I won't change that otherwise.

The workflow looks good, but when peeking at the upstream version I noticed that they don't build for 3.14t yet.

I'll remove the build then.

Alright. It might be something we can add in upstream too, so a future build may have it again.