Modernize release workflow: split build/publish jobs, fix broken steps

[Copilot]

The release workflow had several broken/deprecated issues: non-existent action versions (actions/checkout@v6, actions/setup-python@v6), deprecated ::set-output syntax, and a release-drafter step referencing steps.check-version.outputs.tag which never existed.

Changes

• Structural: Split monolithic release job into separate build and release-pypi jobs (pylint-style), with artifacts passed via upload-artifact@v4 / download-artifact@v4
• Fixed action versions: actions/checkout@v6 → @v4, actions/setup-python@v6 → @v5
• Removed: deprecated check-parent-commit step (::set-output), broken release-drafter step, unnecessary GitHub release upload
• Added: top-level env.DEFAULT_PYTHON: "3.13" and permissions: contents: read; release-pypi job gated on needs: ["build"]

Uv toolchain, Python 3.13, and PyPI OIDC publishing (pypa/gh-action-pypi-publish@release/v1) are unchanged.

Original prompt

Update the GitHub Actions workflow at .github/workflows/release.yml in PyCQA/isort so the release workflow resembles pylint's release workflow structure.

Key requirements:

• Keep the workflow triggered on release: published.
• Remove/disable any steps related to uploading artifacts to GitHub Releases ("We don't need to upload to Github").
• Preserve PyPI publishing via OIDC (pypa/gh-action-pypi-publish@release/v1) and environment pypi.
• Modernize the workflow as appropriate (e.g., avoid deprecated ::set-output; prefer $GITHUB_OUTPUT).
• Ensure checkout action uses a valid version (currently actions/checkout@v6 is not a real release; update to a stable supported version).
• Align naming/steps/layout to match pylint-style conventions (e.g., separate build and publish steps, ensure version/tag handling is clear).

Notes:

• Current workflow uses uv (astral-sh/setup-uv@v7, uv sync, uv build) and Python 3.13; keep uv unless pylint workflow indicates a different approach that makes sense here.
• The workflow currently contains a release-drafter step referencing steps.check-version.outputs.tag which does not exist; adjust or remove it appropriately.

Deliverable:

• Open a PR with the updated .github/workflows/release.yml.
• Include a clear PR description summarizing changes and rationale.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Makes changes to the release file to make it look more like the one from pylint. We don't need to upload to Github.

Assistant: I’m waiting for you to accept or reject the pending change request in the confirmation dialog; once you respond, I can proceed with updating the release workflow accordingly.

This pull request was created from Copilot chat.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.15%. Comparing base (dac090c) to head (d77a2cd).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2522   +/-   ##
=======================================
  Coverage   99.15%   99.15%           
=======================================
  Files          41       41           
  Lines        3092     3092           
  Branches      668      668           
=======================================
  Hits         3066     3066           
  Misses         14       14           
  Partials       12       12           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[DanielNoord]

@staticdev This is heavily inspired on the one used by pylint:
https://github.com/pylint-dev/pylint/blob/main/.github/workflows/release.yml

That one works very well. It is especially good to have the build step different from the release step to ensure that the step executing arbitrary Python doesn't have access to the release token.

Shall we merge this and test with another alpha?