build(python): give RC artifacts unique versions

[XiaoHongbo-Hope]

Summary

• Derive a PEP 440 Python version from the release tag.
• Build v0.3.0-rcN as 0.3.0rcN without changing the Cargo workspace version.
• Validate that the tag base matches workspace.package.version.
• Use the requested release tag for checkout, publication gating, and PyPI index selection.
• Pin release actions and keep Windows version setup on Bash.

Why

RC1 and RC2 currently both build pypaimon-rust 0.3.0. Because TestPyPI publishing uses skip-existing, RC2 can silently reuse RC1 artifacts. Unique RC versions keep retries idempotent while ensuring different RCs publish different files.

Verification

• v0.3.0 keeps dynamic version 0.3.0.
• v0.3.0-rc1 and v0.3.0-rc2 become 0.3.0rc1 and 0.3.0rc2.
• Mistagged and malformed versions fail.
• Manual dispatch checks out and publishes the requested tag.
• Maturin 1.14.1 produced pypaimon_rust-0.3.0rc2.tar.gz with matching PKG-INFO and pyproject metadata.
• Ruff, Python byte compilation, YAML parsing, actionlint, and git diff --check passed.

[JingsongLi]

• The tag provided as input to workflow_dispatch is used only for this release; the checkout does not use this tag, and the build actually runs on the manually selected branch.
• The release job is still restricted by startsWith(github.ref, ‘refs/tags/’), so manual triggers will never result in a release; TestPyPI/PyPI checks also continue to use github.ref rather than the input tag.
• It is recommended to uniformly generate RELEASE_TAG, check out ref: RELEASE_TAG, allow dispatch to proceed to release, and use RELEASE_TAG to determine RC status.

[XiaoHongbo-Hope]

Fixed in 16c2d1a: manual dispatch now uses RELEASE_TAG for checkout, release gating, and TestPyPI/PyPI selection.

[XiaoHongbo-Hope]

Fixed in 16c2d1a: manual dispatch now uses RELEASE_TAG for checkout, release gating, and TestPyPI/PyPI selection.

[QuakeWang]

+1