Parallelize Linux and Docker release jobs

[adamtheturtle]

Summary

• keep the core build job focused on tagging, PyPI publish, Homebrew update, and release creation
• move Linux binary builds into a matrix build-linux job so both binaries build and upload in parallel
• move Docker image publishing into a separate publish-docker job
• remove unneeded packages: write from the build job

Why

Linux binaries and Docker publish are independent once the release exists, so they can run concurrently and shorten release wall-clock time.

---

Note

Medium Risk
Workflow restructuring and permissions changes can break the release pipeline or publish incorrect/missing artifacts if job dependencies, tag refs, or uploads are misconfigured.

Overview
Refactors the Release GitHub Actions workflow to parallelize post-release artifacts. The core build job now focuses on tagging/versioning, publishing to PyPI, updating Homebrew, and creating the GitHub Release, and drops unneeded packages: write permissions.

Linux binaries are moved into a new matrix build-linux job that waits for PyPI propagation, builds both Linux executables in parallel, and uploads them to the existing GitHub Release. Docker publishing is split into a separate publish-docker job that checks out the tagged release and builds/pushes ghcr.io images using needs.build.outputs.new_tag for the version tag.

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