Promote Windows on ARM (win_arm64) to a fully supported platform

[khmyznikov]

Windows on ARM was previously kept in a stability validation period: its wheel was built and smoke-tested but not uploaded, and the arm64 test and wheel-build steps used continue-on-error with soft-failure warnings so problems would not block CI or releases.

This promotes win_arm64 to full support:

• Upload the arm64 wheel like every other platform (drop the arch guard in the windows-wheel action).
• Remove continue-on-error and the "Report soft failure" steps for the arm64 entries in ci.yml and wheel-builder.yml, so arm64 failures are treated as real failures.
• Add Python 3.15-dev arm64 entries for both tests (ci.yml) and wheel builds (wheel-builder.yml).

Maintenance support:

• Python for win_arm64 got promoted to a Tier 2
• No issues with wheel builds or tests were observed in the last months.
• You have me @khmyznikov and @paveliak if you suddenly start observing an issues on gh actions/runner side, in addition to CoreCollective working group.

[khmyznikov]

Additionally, verified the upcoming update for gh runner, currently it's under the name windows-11-vs2026-arm but will be merged to main in a few weeks. I was said it's just vs2026 update. But all good regardless. https://github.com/khmyznikov/cryptography/actions/runs/30566543030/job/90952491264
https://github.com/khmyznikov/cryptography/actions/runs/30566731637/job/90952998822

[reaperhulk]

We're currently planning to restore support in 51 (likely a Sep/Oct release given our history), but we'd like to see one more month of stability before we actually merge. Thanks for working with us on this and helping stabilize the runners.

[khmyznikov]

@reaperhulk Sounds good, Sep would be great.

[jtauschl]

We maintain a Python MCP server package that transitively depends on cryptography via pyjwt[crypto] (pulled in unconditionally by the mcp SDK). It currently fails to install on win_arm64: no wheel, and a source build needs a Rust toolchain plus the MSVC linker, which most end users don't have. We filed the underlying issue in mcp's repo (modelcontextprotocol/python-sdk#3373), but this wheel is the actual fix. No pressure on timing, just confirming there are real users waiting on this.

[showharLaw]

Data point from a Windows ARM64 user: I checked PyPI and none of 47.0.0, 48.0.0, 48.0.1, 49.0.0, 50.0.0, 50.0.1 ship a win_arm64 wheel — 46.0.3 (cryptography-46.0.3-cp311-abi3-win_arm64.whl) appears to be the last one, which pins a lot of downstream users on this platform. Great to hear support returns in 51.

For anyone blocked in the meantime: building 50.0.0 from sdist on native aarch64-pc-windows-msvc works if OpenSSL is vendored. Recipe that produced a working static wheel for me (rustc 1.96.1 aarch64-pc-windows-msvc, MSVC 14.51 Hostarm64\arm64, Strawberry Perl):

1. In the workspace Cargo.toml, change the openssl workspace dep to openssl = { version = "0.10.80", features = ["vendored"] } (pulls openssl-src; OpenSSL itself takes ~20 min to compile).
2. Remove locked = true from [tool.maturin] in the sdist's pyproject.toml (openssl-src changes the lockfile).
3. Set PYO3_PYTHON=<real python.exe> explicitly — on Windows, a bare python in build scripts can resolve to the Microsoft Store alias stub and kill cryptography-cffi's build.rs with "Python was not found".
4. maturin build --release → cryptography-50.0.0-cp311-abi3-win_arm64.whl, functionally verified (SHA-256, RSA sign/verify, x509 self-signed cert, PEM roundtrip).

The resulting wheel is fully static (no libcrypto DLL dependency), same shape as the official ones.