build: align release workflow with sample-plugin standard

[farhan]

What changed

Updates .github/workflows/release.yml to match the current sample-plugin release standard, as established in openedx/sample-plugin#57.

Why

The openedx org now has GitHub immutable releases enabled, which freezes a release's assets the moment it is published. Our flow (like sample-plugin's before #57) published the release first and then attached the distributions in a separate python-semantic-release/publish-action step — which GitHub now rejects with HTTP 422 (Cannot upload assets to an immutable release).

In sample-plugin this silently produced asset-less releases from v3.6.1 onward, and started hard-failing the release job once python-semantic-release v10.6.0+ stopped swallowing the upload error. This repo runs the same flow and would hit the identical failure.

What sample-plugin#57 did (and this PR mirrors)

• vcs_release: "false" on the python-semantic-release step — it still commits, tags, pushes and builds, but no longer creates the GitHub Release itself.
• publish-action is replaced by a gh release create step that creates the release as a draft, uploads the dist/* assets, and only then publishes it — the sequence immutable releases require. PSR's generated notes are reused via the release_notes output so the release body is unchanged.

Adaptations for this repo:

• Bump python-semantic-release v10.6.1 → v10.6.2.
• Pin pypa/gh-action-pypi-publish to a commit SHA (v1.14.2) instead of the floating release/v1 tag. OIDC trusted publishing is preserved (no API token).

Notes

Draft PR — the release workflow only runs on merge to main, so end-to-end behaviour can't be exercised on the branch (same caveat as #57, which validated itself by releasing on merge).

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.17%. Comparing base (a14ce68) to head (fdc7a44).

Additional details and impacted files

@@           Coverage Diff           @@
##             main      #77   +/-   ##
=======================================
  Coverage   82.17%   82.17%           
=======================================
  Files          48       48           
  Lines        1419     1419           
  Branches      110      110           
=======================================
  Hits         1166     1166           
  Misses        221      221           
  Partials       32       32           

Flag	Coverage Δ
unittests	82.17% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[irfanuddinahmad]

Minor: this step is named `Create GitHub Release with Assets`, missing the `Publish | ` prefix that sample-plugin, and your own xblocks-core#297/forum#290 PRs, all use for the same step (`Publish | Create GitHub Release with Assets`). Otherwise matches sample-plugin's pattern exactly.

[irfanuddinahmad]

Since this repo is already uv-native (uv.lock/pyproject.toml), consider going one step further: run PSR via uvx instead of this Docker action, and switch build_command to uv build:

uvx --from "python-semantic-release==10.6.2" \
  semantic-release -v version --no-changelog --no-vcs-release

Avoids pip entirely (in line with the org's uv migration) and is ~2.5-3x faster per run in our testing — PSR's Docker image rebuilds from scratch every run (~40s overhead) vs uvx's ~1s. Non-blocking, up to you whether it's in scope for this PR.