[CI] Make release workflow support RC process

[zpoint]

Summary

• Change scheduled trigger from biweekly (1st/15th) to monthly (1st only)
• Scheduled trigger now creates next minor RC1 (e.g., 0.11.0 → 0.12.0rc1) instead of incrementing patch version
• Add promote_rc_to_stable option to promote latest PyPI RC to stable (e.g., 0.12.0rc2 → 0.12.0) with automatic test skipping
• Fix version verification to use PEP 440 comparison instead of requiring exact next patch version

Fixes #8308

Test plan

Version Logic Verification (manual inspection)

Scenario	PyPI Has	Action	Expected Result
Monthly scheduled	0.11.0	Scheduled trigger	Creates 0.12.0rc1
Monthly scheduled	0.11.0rc2	Scheduled trigger	Creates 0.12.0rc1
Monthly scheduled	0.11.0.post1	Scheduled trigger	Creates 0.12.0rc1
Promote RC	0.12.0rc2	promote_rc_to_stable=true	Creates 0.12.0, skips tests
Promote non-RC	0.11.0	promote_rc_to_stable=true	Fails with error
Manual release	any	release_version=0.12.0rc3	Creates 0.12.0rc3

PEP 440 Version Comparison

The new verification uses Python's packaging library for correct ordering:

• 0.12.0rc1 > 0.11.0.post1 > 0.11.0 > 0.11.0rc2 > 0.11.0rc1

🤖 Generated with Claude Code

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[zpoint]

@Michaelvll Could you confirm the behavior described in the PR? I'm not entirely sure what we should do if a version like 0.11.0rc2 is not promoted to 0.11.0 and the next monthly release cron triggers. Should we proceed with 0.12.0 or skip it?

I'll run manual tests before merging once it's confirmed.

[aylei]

LGTM, thanks @zpoint !