[BUG] PyPy/Windows wheel silently skipped → release validation fails; `build-all` swallows per-interpreter build failures

## Summary The post-merge 26.6.1 development release failed strict fileset validation with: ``` ❌ Missing required wheels: - pypy311-win-amd64 ``` Investigation found two separate defects: 1. **`build-all` (justfile) swallows per-interpreter build failures** — a failing `just build <venv>` does not fail the recipe, so the Windows wheels job goes **green while silently omitting a wheel**. The gap is only caught later, at release time, by `check-release-fileset` (strict). 2. **The PyPy/Windows build aborts while installing the core dependency `cbor2`** — current `cbor2` (6.x) is Rust/pyo3-only and cannot be built on PyPy/Windows. Pinning `cbor2 < 6` *only on PyPy/Windows* lets pip use cbor2's pure-Python wheel there, which unblocks the build. ## Detail ### 1. `build-all` false-green (the real structural bug) ```just build-all: #!/usr/bin/env bash # no `set -e` for venv in {{ENVS}}; do # ENVS = 'cpy314 cpy313 cpy312 cpy311 pypy311' just build ${venv} done ls -la dist/ # last command → recipe exits 0 even if a build failed ``` A failed `just build pypy311` is swallowed; the loop continues and the recipe exits 0 because `ls` succeeds. The Windows job (`wheels.yml`, "Build binary wheels with NVX (Windows)" → `just build-all`) therefore reports success while uploading only `cp311/312/313/314-win_amd64` and **no** `pp311-win_amd64`. This is the same class of defect as #1856 / zlmdb#116 (silent degradation → false-green → caught late), one level up at the orchestration layer. ### 2. Why the PyPy/Windows build currently aborts — and how to fix it From the Windows wheels job log: - The PyPy 3.11 venv is created successfully (uv downloads `pypy-3.11.11-windows-x86_64`), so PyPy provisioning is fine. - `just build pypy311` → `install-build-tools` runs `pip install -e .[build-tools]` (justfile), which installs autobahn's runtime deps, including the **core** dependency `cbor2` (pyproject.toml). - pip resolves the latest **`cbor2 6.1.2`**. cbor2 6.x is implemented **entirely in Rust (pyo3)** — the pure-Python fallback and the `CBOR2_BUILD_C_EXTENSION` toggle that existed in the 5.x line were removed in the 6.0 rewrite (verified: the 6.1.2 sdist contains only `rust/*.rs`, no Python decoder/encoder). There is **no `cbor2` wheel for PyPy/Windows**, so pip builds from sdist, and the Rust extension fails to link: ``` error LNK2019: unresolved external symbol PyPyModule_FromDefAndSpec2 process didn't exit successfully: rustc ... --crate-name _cbor2 ... (exit code: 1) ``` `PyPyModule_FromDefAndSpec2` unresolved is a known pyo3-on-PyPy/Windows limitation — upstream, outside autobahn's control. **The fix:** cbor2 **≤ 5.7.x** is pure-Python with an *optional* C backend and publishes a pure-Python wheel (`cbor2-5.7.1-py3-none-any.whl`); cbor2's own docs note *"On PyPy, cbor2 runs with almost identical performance to the C backend."* So capping `cbor2 < 6` **only on PyPy/Windows** (via a PEP 508 environment marker) makes pip install the pure-Python cbor2 wheel there — no Rust toolchain, no source build, no env var — for both our build venv **and** end users. Every other platform/interpreter keeps cbor2 6.x. NVX itself was never reached in the failing build (cbor2 aborted first). MSVC + PyPy + CFFI is expected to work, so once cbor2 is resolved the PyPy/Windows wheel should build with NVX. This issue **attempts the native NVX build on PyPy/Windows**; if NVX turns out not to compile there, fall back to the exclude+relax path documented under "Fallback" below. PyPy on **Linux** and **macOS** is unaffected (cbor2's Rust build works there and those wheels are already produced). ## Proposed changes (one focused branch) 1. **`build-all` (justfile): fail loudly.** Aggregate per-interpreter build failures and exit non-zero, reporting which interpreter(s) failed (still attempt all, so the report is complete). 2. **`pyproject.toml`: cap `cbor2 < 6` only on PyPy/Windows** via complementary PEP 508 markers, keeping cbor2 6.x everywhere else: ```toml "cbor2>=5.2.0; platform_python_implementation != 'PyPy' or sys_platform != 'win32'", "cbor2>=5.2.0,<6; platform_python_implementation == 'PyPy' and sys_platform == 'win32'", ``` 3. **Keep building PyPy on Windows** and **keep `pypy311-win-amd64` required** in the release manifest — attempt the native NVX build there. (No change to the `targets:` lists.) 4. Changelog entry under 26.6.1 → Build & CI/CD. ## Fallback (only if NVX does not compile on PyPy/Windows) The fail-loud `build-all` (change 1) will make any remaining PyPy/Windows build failure turn the Windows job red instead of hiding it. If that failure is NVX (not cbor2), retreat to: - Exclude pypy311 from the Windows build (build a `cpy*`-only subset there), and - Remove `pypy311-win-amd64` from all three `release.yml` `targets:` lists (development, nightly, stable). ## Acceptance criteria - [ ] A failing per-interpreter build fails the `build-all` recipe (non-zero exit), naming the failed interpreter(s). - [ ] On PyPy/Windows pip installs the pure-Python `cbor2` (`< 6`); all other platforms/interpreters still resolve `cbor2` 6.x. - [ ] The PyPy/Windows wheel (`pypy311-win-amd64`) builds with NVX and is produced by the Windows job — OR, per "Fallback", PyPy/Windows is excluded and de-required consistently. - [ ] The 26.6.1 development/stable release passes strict fileset validation. - [ ] CI green (incl. `ruff check`). ## References - wheels.yml Windows job log: cbor2 6.1.2 sdist build → pyo3 `LNK2019: PyPyModule_FromDefAndSpec2`. - cbor2 5.7.1 ships `cbor2-5.7.1-py3-none-any.whl`; cbor2 6.x is Rust-only (no pure-Python fallback / no `CBOR2_BUILD_C_EXTENSION`). - release.yml `check-release-fileset` (strict): "Missing required wheels: pypy311-win-amd64". - Related: #1856 / zlmdb#116 (same false-green / silent-degradation class). ## Checklist - [x] I have searched existing issues to avoid duplicates - [x] I have provided a minimal reproducible example - [x] I have included version information - [x] I have included error messages/logs