Each patch release currently spawns an ad-hoc patch/v1.84.N branch
that exists only to base the next patch's cherry-picks on, leaving
stale per-patch branches behind and making "what is queued for the
next 1.84.x" hard to answer. Switch to one long-lived line branch
per minor, stable/X.Y.x, created automatically the first time we
tag X.Y.0 on that minor, and tagged on for each subsequent patch.
The gate is ^v?(\d+)\.(\d+)\.0$, so rc / dev / nightly / .post /
patch tags all skip cleanly; the line branch is created exactly
once per minor. Existing release/<tag> behavior is untouched
(additive step), and RC patches keep their current patch/v1.87.0rcN
flow until that gets its own follow-up.
The tag validator required a leading `v`, so dispatching create-release
with `1.84.0` (or `1.84.0rc1`, `1.84.0.dev42`, `1.84.0.post1`) failed
even though those are the new naming convention. Make the leading `v`
optional in both create-release.yml and create-release-branch.yml so
both legacy (`v1.83.10-stable`, `v1.83.14.rc.1`, `v1.82.3.dev.9`,
`v1.82.3-stable.patch.4`, `v1.83.13-nightly`) and new PEP 440 forms are
accepted during the transition. Refresh the input descriptions to show
the new examples.
Extracts release branch creation into a separate reusable workflow
(create-release-branch.yml) that can be triggered independently via
workflow_dispatch or called from other workflows via workflow_call.
create-release.yml now dispatches it as a dependent job after the
release publishes, keeping both workflows decoupled.
