Cut 0.1.0.dev4 and add a two-workflow auto-tag-then-release pipeline

[smaniches]

Two things, in order.

Why: the process broke last time

0.1.0.dev3 was cut in source control by #48, but the tag push that should have followed never happened — my sandboxed session cannot push tags (the git proxy returns 403; only the designated branch push is authorized). Then #49 merged substantial new code (optimizer moment-transport fix, pipeline integration, a preregistered benchmark) on top of that un-tagged commit. Net result: two weeks of real changes on main, never released, never versioned, never deposited to Zenodo.

1. Cut 0.1.0.dev4 (63d001f)

Folds both un-released changesets into one honest release, since 0.1.0.dev3 never separately shipped:

• Version bumped everywhere it's declared: pyproject.toml, groupoid/__init__.py, codemeta.json, CITATION.cff, STATUS.md (both mentions).
• .zenodo.json: version bumped, erratum text extended to describe both the dev3 and dev4 content and to note dev3's non-release. isNewVersionOf already correctly pointed at dev2's real Zenodo DOI (10.5281/zenodo.20787126), since dev3 has none to chain from.
• CHANGELOG.md: Unreleased rolled into [0.1.0.dev4]; the existing [0.1.0.dev3] section is kept for the historical record with a pointer forward, and its compare link repointed at the merge commit (af42cb4) since no tag exists for it.

2. Automate the step that broke — as two single-purpose workflows (e265379, revising a4f2199)

An earlier version of this PR put the auto-tagging logic inside release.yml itself, triggered on both tag-push and push-to-main, with a detect job gating the rest of that same run. Caught in review before merge: GitHub does not re-trigger a workflow from a push made with that run's own GITHUB_TOKEN, so it would not actually have double-published — but that design made the publish path's safety depend on an anti-recursion behavior instead of on visible workflow structure, which is the wrong thing to lean on for something that publishes to a public registry. Reworked into two workflows:

• .github/workflows/release.yml is reverted to exactly its pre-automation form — byte-identical to before this PR. Tag-push and workflow_dispatch only; no branch trigger, no detect job. It does what it always did: build, provenance/SBOM attestation, PyPI publish, Sigstore signing, GitHub Release.
• .github/workflows/auto-tag-release.yml is new and does exactly one thing: on a push to main that touches pyproject.toml, it checks whether the version's tag already exists; if not, it validates the version has a recognized release format (X.Y.Z, optionally .devN/aN/bN/rcN, no local-version metadata) and that CHANGELOG.md documents it, then creates and pushes the tag (as github-actions[bot]) and stops. Nothing else. That tag push is what triggers release.yml, exactly as a manual git tag && git push would.

The result: the actual publish path has exactly one trigger (a tag push) to reason about, structurally — not "two triggers that happen not to double-fire because of how GITHUB_TOKEN works." A push to main with no version change, or an already-tagged version, is a no-op in the tagging workflow and never reaches release.yml at all.

Deliberately not automated: the pypi GitHub Environment gate is untouched. If you have required reviewers configured there, publishing still waits for that approval — this closes the "forgot to tag" gap, not the "should a human approve this publish" decision, which stays yours.

CONTRIBUTING.md documents the resulting two-workflow release process.

3. CI resilience: retry the flaky torch install (a78dfb6)

Unrelated to the release automation, but discovered blocking this PR: two consecutive CI runs both failed identically across lint, test (3.10/3.11), security, benchmark, and docs — every one of them hit SSLV3_ALERT_HANDSHAKE_FAILURE against download-r2.pytorch.org (the CDN behind PyTorch's CPU wheel index) after pip's own internal retries were exhausted. This is a pre-existing step in ci.yml/docs-deploy.yml, untouched by this PR's other changes, and the failure is external (confirmed by hitting the identical error on a full rerun).

Extracted the install into .github/scripts/install_torch_cpu.sh: five attempts with linear backoff (10s/20s/30s/40s), each attempt a completely fresh pip install invocation (a fresh TLS connection — meaningfully different from pip's own internal retries, which reuse one connection pool within a single process), explicit error and exit 1 if all attempts are exhausted rather than silently falling through to a partial environment. All five occurrences of the raw install line across ci.yml and docs-deploy.yml now call this script instead. Verified locally: all three paths (immediate success, delayed success, exhausted failure) exercised directly against a stubbed pip/sleep, each producing the expected exit code.

Important: merging this PR fires a real release

Because 0.1.0.dev4's tag doesn't exist yet, the merge commit itself will trigger auto-tag-release.yml → push v0.1.0.dev4 → release.yml's full pipeline (build, attest, publish to PyPI pending your environment approval if configured, sign, release, and the resulting Zenodo deposit). This is intentional — it's exactly what clears the current backlog — but flagging it so it's not a surprise.

Verification

• 101 tests, 100% line + branch coverage maintained
• ruff, black, mypy --strict, bandit, pre-commit run --all-files, mkdocs build --strict, python -m build (produces groupoid-0.1.0.dev4.tar.gz/.whl): all green
• .zenodo.json/codemeta.json parse as valid JSON; CITATION.cff parses as valid YAML; all workflow files parse as valid YAML with the expected jobs
• The tagging workflow's shell logic (version extraction, format check, existing-tag check, changelog check) dry-run locally against the actual repo state: passes, correctly identifies v0.1.0.dev4 as not yet existing
• git diff against the pre-automation commit confirms release.yml is byte-identical to before this PR

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.