ci: a Create Release run whose Vendor Update was skipped can displace a pending run that has release work #1705

Describe the bug
Create Release's concurrency group (create-release.yml:30-32: cancel-in-progress: false) keeps one running and one pending run. GitHub cancels a pending run when a newer one joins the group. That newer run can come from a Vendor Update that was skipped, in which case it does nothing. So a pending run whose Vendor Update succeeded can be displaced by no-op runs.

The comment at :14-27 says "never cancel a release run" and treats a dropped run as "a publish that did not happen twice". In this case, though, it is a publish that waits for the next successful Vendor Update.

Reproduction
Run 38499150441 (created 2026-10-14T02:04:54Z on 8035434a2, triggered by a successful Vendor Update) ended cancelled while pending. It was displaced by runs 38497304243 and 38497353175, whose Vendor Updates were skipped. Here it cost nothing, because the version had not changed. If the displaced run had been the one carrying a version bump, the release would have been held until the next successful Vendor Update. That impact is inferred, not observed.

Expected behavior
A run that has release work to do is never displaced by one that has none. One way: gate entry to the group on the triggering run's conclusion, so a skipped Vendor Update starts no Create Release run at all. The comment should then describe what the group actually guarantees.