Parallelize release workflow

[adamtheturtle]

Split the single release job into three jobs:

• release: changelog update, commit, tag, GitHub release
• pypi: build and publish to PyPI (runs after release)
• docker: build and push Docker images (runs after release)

The pypi and docker jobs run in parallel after release completes, since Docker images are built from the repository source and don't depend on the PyPI package.

Permissions are scoped to only the jobs that need them:

• contents: write on release only
• id-token: write on pypi only
• permissions: {} on docker

---

Note

Medium Risk
Changes only CI/CD, but it alters release ordering, checkout refs, and permissions, which could break publishing or produce releases from the wrong commit if misconfigured.

Overview
Refactors .github/workflows/release.yml by splitting the prior single release pipeline into three jobs: release (changelog update/commit, tag/version calculation, and GitHub release creation) followed by pypi (build + publish to PyPI) and docker (build + push multi-arch Docker images) running in parallel.

The release job now exposes version and tag as job outputs, and downstream jobs check out the repository at the created tag instead of doing manual git fetch/checkout. Permissions are tightened so only release has contents: write, only pypi has id-token: write, and docker runs with permissions: {}; Docker tags now use needs.release.outputs.version.

^{Written by Cursor Bugbot for commit 4e0a8e8. This will update automatically on new commits. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}