ci(release): hold a line's first stable to its newest beta

[datlechin]

Why

After a refused v0.82.0 (a pick landed after the newest beta), the tag stays and no beta of 0.82.0 can follow. The refusal said "ship that in a beta first", which cannot happen, and v0.82.1 then passed with the same untested pick because patches were exempt. Follow-up to #3543.

Change

• version.py check holds every stable on a line to its newest published beta until a stable tag on the line has matched it. A fix after a matching X.Y.0 that failed later in its run still ships as the next number.
• The refusal now names a step that can follow: revert the changes on release/X.Y, then tag the next number.
• RELEASING.md, What a tag runs: the verify bullet names the wider refusal.

Verified

python3 -m unittest test_version on Python 3.9. New cases: X.Y.1 carrying the late pick is refused and X.Y.2 with it reverted builds; X.Y.1 after a matching, unpublished X.Y.0 builds. test_a_stable_refuses_a_change_after_its_newest_published_beta changed with the new wording.

Not in this PR

• A release PR check that compares the line with its newest beta before any tag exists (scripts/ci/check-changelog.py).