[tbitcs]

Prepared (unmerged) release infrastructure, spun up alongside the first PyPI publication of axiomere 0.1.0.

Why

Two distributions exist by design:

• axiomere (this repo) — the pure-Python wrapper: hatchling sdist + py3-none-any wheel. PyPI-acceptable as-is and publishing now.
• axiomere-py (AXIOVEX/axiomere, crates/axiomere-py) — the native PyO3 extension _axiomere, which the wrapper requires. A locally built extension wheel is tagged linux_x86_64, which PyPI rejects; today, users without a prebuilt wheel need a local Rust toolchain + maturin (the README route).

What this adds

.github/workflows/release-wheels.yml:

• build-extension-wheels — cibuildwheel matrix (Linux x86_64 + ARM64, Windows, macOS Intel + Apple Silicon) × CPython 3.10–3.13 against the core crate, with rustup installed inside the manylinux containers (CIBW_BEFORE_ALL_LINUX) and a per-wheel smoke test (import _axiomere + keypair generation) via CIBW_TEST_COMMAND.
• build-wrapper — python -m build sdist + wheel for this repo.
• publish — tag-gated (v*) job that splits artifacts by project and publishes via pypa/gh-action-pypi-publish. It expects PyPI Trusted Publishing (OIDC) to be configured for both projects first; until then it fails at the publish step by design. No API tokens are stored in the repo.

Honest status

• This workflow has not been run yet. Expect a workflow_dispatch shakedown and small fixes (the core-checkout ref should be pinned per release; the split-glob step deserves one real run) before the first tagged release relies on it.
• It changes no packaging in either repo and does not affect the existing CI.

Follow-ups for whoever merges

1. Configure Trusted Publishing for axiomere and axiomere-py on PyPI, or swap the publish job for a token-based step kept outside the repo.
2. Decide the release-time core pin policy (the comment in the checkout step).
3. Once extension wheels exist on PyPI, simplify the README install section to pip install axiomere axiomere-py.