feat(vcluster-release): check release.yaml before tagging, through release-lib

[sydorovdmytro]

Summary

• vcluster-release sources release-lib for its routing helpers instead of carrying 11 copies, and runs platform-release's dispatch preflight (require_dispatchable + require_workflow_active, now in release-lib) before any tag, on every path. Legacy lines check both repos before OSS is tagged, and pro again at the head the dependency bump leaves.
• source_branch is forwarded to lines whose release.yaml declares it, for the notifier's base_branch. A resumed tag must be on the branch the cut routes to (require_tag_on_target), and a rejected dispatch says the tag is left for a re-run.
• source-branch is trimmed and validated as a branch name, as in platform-release. Versions follow the lib's stricter grammar.
• The preflight needs mikefarah yq on the runner. The only caller, vcluster-pro's cut-release.yaml, runs on GitHub-hosted Ubuntu, which ships it, so this advances vcluster-release/v1 after merge. Every live line (vcluster-pro main, v0.37, v0.34–v0.36; vcluster v0.34–v0.36) passes the preflight as-is.

References DEVOPS-1364
References DEVOPS-1598

Test plan

• make test-vcluster-release with mikefarah yq v4.47.1: 236/236
• make test-platform-release: 335/335
• make test-release-lib: 39/39
• shellcheck -x on the three scripts, make lint (actionlint + zizmor), make generate-docs with no drift
• require_dispatchable run against the live release.yaml on each line listed above

[loft-bot]

Panel review: 1 blocking, 3 quality notes, 11 lanes.

Blocking concerns

• .github/actions/vcluster-release/test/vcluster-release.bats:2653: no legacy test checks that source_branch is left out when release.yaml doesn't declare it. Making cut_legacy always forward it leaves the whole suite green.

What was checked

Checked: correctness, security, test-quality, operability, reuse, architecture, dead code, typos, coverage gaps (against DEVOPS-1364 / DEVOPS-1598 acceptance criteria), PR metadata. Skipped: e2e, infra, entry-point fidelity, layout (no e2e or infra files, no customer bug, not a restructure).

Quality notes (non-blocking)

• consider: .github/actions/vcluster-release/test/vcluster-release.bats:2674. Could we add a legacy case where OSS is already dispatched and only the pro dispatch fails? Today only the OSS failure is exercised. This becomes blocking if the pro dispatch's failure message stops naming loft-sh/vcluster-pro and the tag left behind.
• consider: .github/actions/vcluster-release/src/vcluster-release.sh:966. Could require_dispatchable hand back the input list it checked, so the four call sites stop rebuilding -f args from globals? This becomes blocking if a caller's rebuilt list drifts from the checked one and a dispatch fails after tagging.
• consider: .github/actions/vcluster-release/test/vcluster-release.bats:145. The stub answers the new tag and compare reads with pre-built values, so the real --jq filters in resolve_tag / require_tag_on_target never run. This becomes blocking if one of those filters is edited.

[sydorovdmytro]

On the non-blocking notes:

• Pro dispatch failing after OSS was dispatched: added in abd3eaf. The test checks that OSS is reported as already dispatched and that the error names loft-sh/vcluster-pro and the tag left behind.
• require_dispatchable handing back the inputs it checked: agreed it's the cleaner shape. It also changes platform-release's dispatch, so I'd rather do it together with folding the two dispatchers' preflight wiring into one lib helper, as a follow-up instead of in this PR: DEVOPS-1675.
• The stub answering tag and compare reads with pre-built values: those filters live in release-lib. resolve_tag's filter runs against real JSON with real jq in release-lib/test/lib.bats, and require_tag_on_target's .status // empty runs through platform-release's stub, which pipes JSON bodies through the caller's --jq. An edit to either filter is caught there.