ci: create a GitHub Release per version tag

[carolsimone]

What this changes

Adds .github/workflows/release.yml, adapted from continuo's workflow of the same name, so a version tag produces an actual GitHub Release.

Why

publish-pypi.yml and images.yml already do the real work of a release (PyPI trusted publishing; building + smoke-testing + pushing both engine images to ghcr.io), each independently on their own push: tags: v* trigger. Neither of them creates a GitHub Release, and PyPI's release list only ever knows about the two packages — not the two ghcr.io images a tag also ships. A Release is the one place to say "this tag = these packages + these images."

What was stripped from continuo's version, and why

continuo's release.yml is a 5-job pipeline (retag-images, install-test, publish-chart, smoke-published-chart, github-release) built around things this repo does not have: a Helm chart, a Kubernetes deploy directory, a self-hosted runner, a kind cluster, and a separate deploy.yml that builds images once for retagging later. None of that applies here — images.yml builds and pushes the images directly on the tag, it isn't retagging a pre-existing sha-tagged image. So this PR keeps only the equivalent of continuo's github-release job.

The one real design problem this repo's version has to solve that continuo's didn't

continuo's github-release job uses needs: on jobs in the same workflow file. Here, the two things this job needs to wait for — publish-pypi.yml and images.yml succeeding — are separate workflow files triggered independently by the same tag push, and needs: can't cross files. I considered workflow_run (fire when either sibling completes, check if the other already finished too) but rejected it: it depends on workflow_run.head_branch correctly carrying the tag name for a tag-triggered source run, which nothing else in this repo relies on, so I'd be introducing an assumption I can't verify.

Instead, release.yml triggers on the same push: tags: v[0-9]* as its siblings and polls the Actions API (gh api repos/.../actions/workflows/{file}/runs -f head_sha=... -f event=push) for each sibling's conclusion at this exact commit, up to a 30-minute timeout per sibling. event=push specifically avoids picking up one of images.yml's pull_request-triggered runs by accident. Any non-success conclusion (or a timeout) fails the job outright rather than silently skipping the Release.

Other details:

• -test tags (e.g. v0.3.1-test1) are excluded — those are publish-pypi.yml's TestPyPI dry run, and images.yml's publish job already skips itself for them by design.
• Release creation is idempotent (gh release view → edit or create), matching continuo's pattern, in case this ever re-runs against an existing tag.
• No CHANGELOG.md exists anywhere in this repo (unlike continuo's deploy/continuo/CHANGELOG.md), so there's no changelog-extraction step to port — notes are always --generate-notes.

How it was verified

• YAML validated: python3 -c "import yaml; yaml.safe_load(open('.github/workflows/release.yml'))".
• Not verified: the actual cross-workflow wait/poll behavior. That needs a real v* tag push to exercise — a PR can't trigger it, and there's no local way to simulate publish-pypi.yml/images.yml completing. The next tag push (v0.3.1) will be the first real test; worth watching that run closely.

Checklist

• Every commit is signed off (git commit -s)
• Tests added or updated for the behavior changed — no test harness exists for GitHub Actions workflow files in this repo; verification is YAML validation plus the reasoning above
• scripts/security-scan.sh not relevant (no dependency or credential changes)