refactor(ci): remove redundant release-branch input from github-release.yml

[MAfarrag]

Context

.github/workflows/github-release.yml exposes a workflow_dispatch input named release-branch (default "main")
that is used as ref: in the checkout step and as the explicit target of git push origin "$RELEASE_BRANCH" in the
lockfile commit step.

That input is redundant with GitHub's built-in "Use workflow from" dropdown (the dispatch ref) and creates a latent
silent-failure path when the two values diverge. The convention of "set them to the same value" hides the failure
mode but doesn't prevent it.

Problem / Current Behaviour

The dispatch ref (the dropdown) sets github.ref / github.ref_name inside the run AND workflow_run.head_branch
for any downstream listener (e.g. bundle-pypi-wheels.yml). The release-branch input does NOT influence any of
those; it only controls what actions/checkout writes into the working tree.

Failure scenario today: a release dispatched with dropdown = main but input = release/0.36.0.

1. github-release.yml correctly checks out release/0.36.0, bumps + tags + pushes to it.
2. GitHub fires workflow_run with head_branch = main (the dispatch ref, frozen at dispatch time).
3. bundle-pypi-wheels.yml resolves ref: ${{ github.event.workflow_run.head_branch || ... }} → main, checks
   out main's tip.
4. Working tree is old-version source. cibuildwheel builds old-version wheels.
5. gh release view returns the new tag. gh release upload <new tag> dist/*.whl attaches the old wheels under
   the new tag. PyPI publishes the wrong wheels.

This only fails to happen today because the dispatching convention is to keep both fields equal. Nothing in the
workflow enforces it.

Affected locations

File	Symbol	Notes
.github/workflows/github-release.yml	on.workflow_dispatch.inputs.release-branch	The redundant input.
.github/workflows/github-release.yml	release job → "Checkout repository"	ref: ${{ inputs.release-branch }} to remove.
.github/workflows/github-release.yml	release job → "Commit and push updated lockfile"	env.RELEASE_BRANCH + git push origin "$RELEASE_BRANCH" to simplify.

Steps to Reproduce / Motivation Example

Today the input is used like this (excerpt):

on:
  workflow_dispatch:
    inputs:
      release-branch:
        description: "Branch to create release from"
        required: false
        default: "main"

jobs:
  release:
    steps:
      - uses: actions/checkout@…
        with:
          fetch-depth: 0
          ref: ${{ inputs.release-branch }}
      …
      - name: Commit and push updated lockfile
        env:
          RELEASE_BRANCH: ${{ inputs.release-branch }}
        run: |
          …
          git push origin "$RELEASE_BRANCH"

workflow_run.head_branch carries the dispatch ref, not inputs.release-branch. Recent runs confirm this
(every headBranch value matches the release branch the user picked in the dropdown):
28050001891 → release/0.36.0, 27647051513 → release/0.35.0, 27511221111 → release/0.34.0,
27495839883 → release/0.33.0, 27109197153 → release/0.32.0.

Proposed Solution

Three small edits in .github/workflows/github-release.yml:

 on:
   workflow_dispatch:
     inputs:
-      release-branch:
-        description: "Branch to create release from"
-        required: false
-        default: "main"
       increment:
         …

       - name: Checkout repository
         uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0  # v7.0.0
         with:
           fetch-depth: 0
-          ref: ${{ inputs.release-branch }}

       - name: Commit and push updated lockfile
-        env:
-          RELEASE_BRANCH: ${{ inputs.release-branch }}
         run: |
           git config user.name "github-actions[bot]"
           git config user.email "github-actions[bot]@users.noreply.github.com"
           git add pixi.lock
           git diff --cached --quiet && echo "No lockfile changes" && exit 0
           git commit -m "build: sync pixi.lock after version bump"
-          git push origin "$RELEASE_BRANCH"
+          git push

actions/checkout without ref: defaults to github.ref (the dispatch ref). After the checkout above, git push
in the lockfile step pushes the current branch back to its tracking remote — same end result as the explicit
git push origin "$RELEASE_BRANCH".

How to use after the change:

1. Create release/<version> from main locally and push it (unchanged from today).
2. Actions → github-release → "Run workflow" → pick release/<version> in the "Use workflow from" dropdown.
3. Fill increment, prerelease_type, draft. No more release-branch field.
4. Downstream bundle-pypi-wheels.yml keeps working because workflow_run.head_branch still equals
   release/<version> (same value that today's correct runs already produce — see the run IDs above).

Out of Scope

• Any change to bundle-pypi-wheels.yml. The chain is unaffected when the dispatch ref equals the release branch
  (which becomes the only supported flow after this change).
• Moving release-branch creation into the workflow itself (separate design discussion — workflow_run cannot carry
  a branch created mid-run).
• Any change to the release/github composite action.

Effort Estimate

Size: XS
Rationale: three localised edits in one file; one manual end-to-end release run to verify.

Definition of Done

• release-branch input removed from .github/workflows/github-release.yml.
• Checkout step uses the default ref (no ref: line).
• Lockfile commit step uses plain git push and the RELEASE_BRANCH env block is removed.
• A test release on a release/<test-version> branch (dispatched via the dropdown) produces
  correctly-versioned wheels attached to the new tag and published to PyPI under that new version.
• No remaining references to inputs.release-branch anywhere in the workflow file.