bug(ci): github-release.yml creates the release/tag before the flaky pixi lock and has no timeout-minutes

[MAfarrag]

Context

Surfaced during a workflow audit. github-release.yml cuts the GitHub release + version tag via commitizen, then
syncs pixi.lock. On this project pixi lock is known to be flaky / hang-prone (project convention prefers
pixi update), and the job has no time cap.

Problem / Current Behaviour

Two coupled issues in the release job:

1. No timeout-minutes on the release job (nor on the reused pure-wheel-test jobs). A hung pixi lock
   runs to GitHub's 6-hour default before the job is killed.
2. Ordering strands the release on failure. The steps run: create GitHub release + tag (lines 65-73) ->
   pixi lock (line 76) -> commit/push lockfile (lines 78-87). If pixi lock hangs or fails, or the push fails,
   the release and tag already exist, but the downstream bundle-pypi-wheels.yml build is gated on
   github.event.workflow_run.conclusion == 'success' — so a failed github-release leaves a published tag/
   release with no wheels on PyPI and an unsynced lockfile, requiring manual recovery.

Affected locations

File	Symbol	Notes
.github/workflows/github-release.yml	release job (lines 42-87)	no timeout-minutes
.github/workflows/github-release.yml	Create GitHub Release with Commitizen (65-73)	creates tag/release first
.github/workflows/github-release.yml	Update lockfile after version bump -> pixi lock (76)	flaky, uncapped, runs after
.github/workflows/github-release.yml	Commit and push updated lockfile (78-87)	push failure also strands the tag

Steps to Reproduce

Trigger a release. If `pixi lock` hangs -> job burns ~6h (no timeout). If `pixi lock` (or the push) fails after
the commitizen step -> the GitHub release + version tag exist, bundle-pypi-wheels never runs (gated on
github-release success), so the tag has no wheels on PyPI.

Proposed Solution

• Add timeout-minutes to the release job (and the pure-wheel-test jobs it reuses).
• Reorder so a lockfile/push failure cannot strand a tag: either sync + commit pixi.lock before creating the
  release, or make release creation the final step. Consider pixi update over pixi lock per project convention.

  release:
    needs: pure-wheel-test
    runs-on: ubuntu-latest
    timeout-minutes: 30
    ...
    # sync + commit pixi.lock, THEN create the release/tag last

Out of Scope

• Fixing pixi lock flakiness itself (upstream/tooling).
• The release-branch input cleanup tracked in refactor(ci): remove redundant release-branch input from github-release.yml #613.

Effort Estimate

Size: S — add timeouts + reorder two steps; verify a release still cuts cleanly.

Definition of Done

• release (and reused) jobs have a timeout-minutes.
• A pixi lock/push failure can no longer leave a published tag without wheels (lockfile synced before the
  release, or release created last).
• A normal release still produces the tag, synced lockfile, and downstream wheels.