Fix release automation: explicitly dispatch release.yml instead of relying on the tag push

[smaniches]

The bug, confirmed on the actual #50 merge

auto-tag-release.yml pushed the release tag using the workflow's own default GITHUB_TOKEN and assumed that push would trigger release.yml's push.tags listener, the way a manual git tag && git push would. It does not: GitHub suppresses push-triggered workflow runs caused by a GITHUB_TOKEN-authored push, specifically to prevent workflows from recursively triggering each other.

Confirmed directly: auto-tag-release.yml ran successfully on the #50 merge and pushed v0.1.0.dev4, but no release.yml run was ever created for that tag, no GitHub Release exists for it (404), and PyPI is still at 0.1.0.dev2. My mistake — I used this exact GitHub behavior to argue the two-workflow split was safe from double-firing, without working through that it also means the second workflow never fires at all.

The fix

• auto-tag-release.yml: after pushing the tag, explicitly dispatches release.yml via gh workflow run (workflow_dispatch is the documented exception to the push-suppression above), passing the tag as both the dispatch ref and the ref input, plus a new create_github_release: true. Gains an actions: write permission to make that call.
• release.yml: gains a create_github_release workflow_dispatch input (default false, preserving the existing "republish an already-released tag to PyPI only" behavior for a plain manual dispatch).
  • sign-and-release now runs on a real tag push or create_github_release == 'true', instead of only on a tag push.
  • The release step sets tag_name explicitly rather than relying on ref inference, so it's correct for both trigger types.
  • The PyPI publish step sets skip-existing: true, so a re-dispatch or an out-of-band manual republish of an already-published version doesn't fail the job.
  • push.tags and the existing ref-only manual-republish path are otherwise unchanged — a human pushing a tag with their own credentials isn't subject to the GITHUB_TOKEN suppression, so that path still works exactly as before.
• CHANGELOG.md / CONTRIBUTING.md: corrected to state the real trigger mechanism instead of the false "the tag push triggers release.yml" claim.

Verification

• Both workflow files parse as valid YAML with the expected jobs and workflow_dispatch inputs.
• The embedded shell script's syntax checked with bash -n.
• Full local gate unaffected (101 tests at 100% coverage, ruff, black, mypy --strict, bandit, pre-commit) — none of this touches groupoid/ or tests/.

Recovery for the still-unreleased v0.1.0.dev4

Once this merges, release.yml can be dispatched directly against the existing tag with ref=v0.1.0.dev4 and create_github_release=true, publishing the version that's been sitting tagged but unreleased since #50 merged — without deleting or recreating that tag. I can run that dispatch once this PR is merged, if you'd like.

[chatgpt-codex-connector]

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