ci: improve release workflows

[jackye1995]

1. use relative release note for beta releases. Example fix: https://github.com/jackye1995/lance/releases/tag/v4.0.0-beta.5
2. ensure RC voting period is correct. Example fix: [VOTE] Release Candidate v4.1.0-rc.3 jackye1995/lance#73
3. implement minor release in release branch:
   • Example proper failure when trying to create minor release in release branch when main branch is not at major version: https://github.com/jackye1995/lance/actions/runs/21975317405/job/63485677361
   • Example successful minor release in release branch: [VOTE] Release Candidate v3.1.0-rc.1 jackye1995/lance#80, https://github.com/jackye1995/lance/releases/edit/v3.1.0-rc.1, https://github.com/jackye1995/lance/releases/edit/v3.1.0

[github-actions]

Code Review

This PR makes two improvements to the release workflows:

1. create_rc.sh: Correctly determines RELEASE_TYPE (major/minor/patch) based on version components instead of hardcoding patch
2. publish_beta.sh: Uses relative release notes for beta releases (beta.2+ compares against previous beta instead of release-root)

Feedback

P1 - Potential bug in publish_beta.sh:

The BETA_NUM extraction uses sed, which assumes the version always contains beta. However, this parsing happens after the bump, where NEW_VERSION should always be a beta version due to the earlier validation at line 24. This appears safe, but consider adding a defensive check or comment clarifying that NEW_VERSION is guaranteed to be a beta version at this point.

Minor observation:

The PR description mentions point 3 with no content - appears to be an incomplete description. No action required for the code itself.

Overall the changes look reasonable and address the stated goals.