ci(release): give the release job's tests a base interpreter, as compat already has (#200)

v1.5.1 tagged, failed, and deleted its own tag — the gate working. Every
failure was in test/test_cli.py with the same cause:

  RuntimeError('Could not find a suitable base Python interpreter ... set the
  SYSTEM_PYTHON environment variable to point to a working Python interpreter
  that can create virtual environments.')

The venv-building CLI tests run the analyzer, which provisions a virtualenv for
the project under analysis, and inside uv's own venv the base-interpreter
discovery walk has no anchor on a runner.

The compat job directly above already sets SYSTEM_PYTHON and passes; the release
job never did and fails. Same defect as python-sdk#332, and found the same way:
by a tag deleting itself.

The variable has to come from this job's own setup step. steps.py310 belongs to
compat and would expand to an empty string here, and the two jobs use different
interpreters deliberately — compat is 3.10, release is 3.12 because the framework
integration tests are gated python_version >= '3.11'. So the setup step gains an
id and the test step reads that. The path must be absolute: the override is
checked with Path(...).exists() and never searches PATH, which setup-python's
python-path output satisfies.

Closes #199

Author: rahlk

.github/workflows/release.yml

@@ -61,6 +61,7 @@ jobs:
       # `importorskip` and the decorator-rule regression they exist to catch would
       # ship green. The `compat` job above keeps 3.10 covered.
       - name: Set up Python 3.12
+        id: py312
         uses: actions/setup-python@v5
         with:
           python-version: '3.12'
@@ -99,6 +100,15 @@ jobs:
         id: test
         continue-on-error: true
         run: uv run pytest
+        env:
+          # Same reason as the `compat` job above, and it has to be repeated per job:
+          # the venv-building CLI tests must find a base interpreter that can create
+          # virtual environments, and inside uv's own venv the discovery walk has no
+          # anchor on the runner. Must be this job's own setup step -- `steps.py310`
+          # belongs to `compat` and would expand to an empty string here. Must be an
+          # absolute path, because the override is checked with `Path(...).exists()`
+          # and never searches PATH.
+          SYSTEM_PYTHON: ${{ steps.py312.outputs.python-path }}
 
       # MUST be `outcome`, not `conclusion`: continue-on-error rewrites `conclusion` to
       # `success`, so a `conclusion == 'failure'` guard never fires and a red test run