Add stable PyTorch 2.13 and manylinux wheel support

[kierandidi]

Summary

• build stable PyTorch 2.13/cu130 wheels for Python 3.12-3.14 on x86_64 and aarch64
• publish the complete GPU and CPU matrix as auditwheel-repaired manylinux_2_28 wheels
• select C++20 only for PyTorch 2.13+ and keep exact Torch/CUDA variants isolated
• validate exact release manifests, clean installs, glibc-2.28 portability, and native GPU loads
• align wheel discovery and release/install documentation for v0.1.42

Test plan

• Build and auditwheel-repair all 24 GPU and 8 CPU wheel lanes
• Pass all 32 clean-environment installs and native extension loads
• Pass representative glibc-2.28 portability checks on both architectures
• Pass the self-hosted GPU runtime wheel smoke
• Pass repository CI
• Publish and verify v0.1.42 after merge

Latest repository CI: https://github.com/uw-ipd/tmol/actions/runs/29602415794
Latest wheel validation: https://github.com/uw-ipd/tmol/actions/runs/29602415232
Validated complete wheel run: https://github.com/uw-ipd/tmol/actions/runs/29596189327

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.10%. Comparing base (ab9a0cb) to head (e82f7bf).
⚠️ Report is 9 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #398      +/-   ##
==========================================
+ Coverage   89.54%   90.10%   +0.55%     
==========================================
  Files         356      358       +2     
  Lines       30990    31401     +411     
==========================================
+ Hits        27751    28293     +542     
+ Misses       3239     3108     -131     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[aleaverfay]

This is perfect timing: I was just looking to add a cuda 13.0 + torch 2.13 build

[aleaverfay]

What is the limit on the number of wheels we can ask github to make / store?

[kierandidi]

GitHub's release limits leave plenty of room for this matrix: up to 1,000 assets per release, each under 2 GiB, with no aggregate release-size or download-bandwidth limit. This release has 32 wheel assets; the validated artifacts total about 2.69 GB and the largest wheel is about 98 MB.

The workflow matrix is also well below GitHub Actions' 256-job matrix limit. Temporary Actions artifacts are separate from permanent release assets and expire (90 days by default); we can shorten their retention later if desired, but that does not constrain the published wheels.

References:

• https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases#storage-and-bandwidth-quotas
• https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs#about-matrix-strategies

The v0.1.42 candidate is ready for maintainer approval once the two transient wheel jobs finish their rerun. After approval I will merge, push the matching v0.1.42 tag, and verify all 32 release assets.

[kierandidi]

Update: the rerun completed successfully. All repository CI and all 32 wheel smoke/portability lanes are green on the current head; maintainer approval is now the only remaining merge gate.