build: align release workflow with sample-plugin standard

[farhan]

What changed

Updates the asset-upload step in .github/workflows/release.yml to match the 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.
• Bump python-semantic-release v10.5.3 → v10.6.2.

Scope / what is intentionally left unchanged

• npm/frontend build steps (setup-node, npm ci && npm run build) are kept as-is — xblocks-core builds frontend assets before releasing.
• PyPI publishing stays token-based (user: __token__ + PYPI_UPLOAD_TOKEN); this PR does not switch it to OIDC.
• Existing upload-artifact / download-artifact pins are already correct and untouched.

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

[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.