fix(deps): pin cbor2<6 to restore Windows x86 wheel coverage

[thomasht86]

Summary

Fixes the Windows x86 release-job failure on the v0.4.5 run: https://github.com/thomasht86/httpr/actions/runs/25425225710/job/74577242234.

Root cause

The dependency bump in #63 left cbor2 unpinned. After cbor2 6.0.1 was released (2026-04-28), the lockfile resolved to it for Python ≥ 3.10. cbor2 6.0+ rewrote the C extension and dropped both the win32 wheel and the py3-none-any.whl pure-Python fallback — only win_amd64 and win_arm64 ship. So when the windows (windows-latest, x86) job runs uv sync --extra dev --find-links dist --reinstall, uv has no installable wheel for cbor2 on win32 and falls back to building from sdist, which fails on the runner. The other Windows job (x64) was cancelled because x86 failed first.

cbor2 5.x ships cbor2-5.9.0-py3-none-any.whl, which uv installs cleanly on win32.

Fix

• pyproject.toml: cbor2 → cbor2<6 in the dev extras.
• uv.lock: regenerated; cbor2 collapses from a per-Python-version split (5.9.0 for <3.10, 6.0.1 for ≥3.10) to a single 5.9.0 entry. Net change is −61 lines.

tests/unit/test_cbor.py and tests/unit/cbor_test_server.py only call cbor2.dumps, so 5.x is functionally equivalent for what we exercise.

Test plan

• uv lock succeeds; cbor2 resolves to 5.9.0 with py3-none-any.whl available.
• Windows verification: the windows job is gated on startsWith(github.ref, 'refs/tags/') || github.event_name == 'workflow_dispatch' (CI.yml:148), so this PR alone won't run it. To verify the fix, trigger the CI workflow via Actions → "Run workflow" against branch claude/fix-ci-failure-OwPVI, or cut a test tag from this branch.
• After verification, re-tag v0.4.5 (or cut v0.4.6) from main post-merge to ship the release that chore(deps): move benchmark deps to PEP 723 scripts, patch vulns #63 attempted.

---

Generated by Claude Code