fix(release): fold refreshed lockfile into the version-bump commit

[MAfarrag]

Description

cz bump commits the version bump and creates the tag atomically, but uv/pixi lockfiles can only be
regenerated after the new version is written to pyproject.toml. So the tag has always pointed at a commit whose
lockfile still pins the pre-bump versions. Consumers work around this with a follow-up commit that syncs the lock
past the tag, which leaves the tagged tree stale: git checkout <tag> && uv sync --locked mismatches (especially
in uv workspaces with many == cross-pins).

This PR folds the refreshed lockfile into the version-bump commit before anything is pushed, so the tag itself
contains a consistent lock — no follow-up commit, no force-push of published refs.

What the fix does (new step in actions/release/github/action.yml, between the bump and the push):

1. cd to the repo root (workspaces keep the lock at the top even when WORK_DIR is a sub-package).
2. Verify HEAD is the tagged commit — if the first-release recovery path ran (cz bump --files-only, which does
   not tag), skip with a warning rather than amend the wrong commit.
3. Refresh the lock via uv lock / pixi lock. Hard-fail on solver/network errors rather than ship a stale lock.
4. If the lock changed: git add, git commit --amend --no-edit --no-verify, then git tag -f <version> onto the
   amended commit.
5. Sanity-check the tag now points at HEAD.

The existing push step then publishes the amended commit and the re-pointed tag as if that had been the state all
along. pip is skipped (no native lockfile).

Also in this PR — the release test suite (.github/workflows/test-release-github.yml) was only runnable under
its push: branches: [main] trigger: every job hard-codes git push origin main, and the action itself does a bare
git push, both of which need a local main. Dispatching the suite on a feature branch died at setup with
src refspec main does not match any, so the suite could never be validated pre-merge. A per-job normalize step
(git checkout -B main + git config push.default current) makes the whole suite runnable from the Run-workflow
button on any branch. This is how the fix below was validated in real CI.

Issues

• Fixes enhancement(release/github): fold the refreshed lockfile into the version-bump commit so the tag is reproducible #14 — release/github: fold the refreshed lockfile into the version-bump commit so the tag is reproducible

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Full suite dispatched on this branch and all 34 jobs pass
(run: https://github.com/serapeum-org/github-actions/actions/runs/29693095409). New/affected jobs:

• Test release - lockfile folded into tag (uv) — proves the fold amends + retags with a refreshed uv.lock;
  asserts the tagged lock differs from the pre-release snapshot, records the new version, HEAD is the tagged
  commit, there is no follow-up commit past the tag, and a re-lock is a no-op (the issue enhancement(release/github): fold the refreshed lockfile into the version-bump commit so the tag is reproducible #14 acceptance check).
• Test release - lockfile folded into tag (pixi) — a version-only bump does not change this fixture's
  pixi.lock (the project is not a pypi/editable dep of its own env), so the fold correctly no-ops; asserts the
  invariants that hold either way: tag on the bump commit, no follow-up commit, tagged lock satisfies a re-lock.
• Test release - pip unaffected by lockfile fold — pip has no lockfile, so the fold step is guarded off; the
  tag stays on the bump commit with no amend and no lockfile is produced.

The core bump → lock → amend → retag mechanic was also reproduced locally against the real uv fixture with
uv + commitizen, confirming uv lock records the new version and git checkout <tag> yields a consistent lock.

Checklist:

• updated version number in pyproject.toml. (n/a — actions are released via namespaced tags, e.g. github-release/vX)
• added changes to History.rst. (n/a — repo has no History.rst)
• updated the latest version in README file. (done at release-tag time)
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes. (full suite green in CI, link above)
• documentation are updated. (follow-up: note in the action README that uv/pixi lockfiles are now inside the release tag)