Align the hand-rolled pipeline to the release vocabulary (hyperi-ci 2.10)

[catinspace-au]

vector-vrl is the one repo that hand-rolls its pipeline against hyperi-ci's internals rather than calling the reusable workflow, so it picks up none of the release-vocabulary change automatically and will drift as the internals move. Nothing is broken today. Every item below still works; each one is a name that is being retired behind a deprecation warning.

There is no .hyperi-ci.yaml here, so this is all in .github/workflows/ci.yml.

WHY THIS REPO IS DIFFERENT

The reusable python-ci.yml assumes the checkout root is the project and has no wheel matrix, which is why this repo reuses the composite actions piece by piece instead. That is a reasonable call and nothing here asks you to change it. The cost is that every rename in hyperi-ci lands as a manual edit here, where a reusable-workflow consumer gets it for free.

WHAT TO CHANGE

1. Gate output. The predict-version composite now emits will-release. will-publish is still emitted with the same value and is not going away -- a reusable workflow cannot warn about an output a caller reads -- but the canonical name is will-release.

   plan job outputs, line 67:
   will-publish: ${{ steps.predict.outputs.will-publish }}
   becomes
   will-release: ${{ steps.predict.outputs.will-release }}

   Then the three reads: needs.plan.outputs.will-publish becomes needs.plan.outputs.will-release, in the stamp-version step, the tag-and-publish job condition, and the wheel build gate.

2. Stage name. hyperi-ci run publish becomes hyperi-ci run release. The publish spelling is kept as an accepted stage alias specifically because this repo invokes it directly -- you are the reason that alias exists -- so there is no deadline on this one.

   Publish to PyPI step:
   run: ${{ env.HYPERCI_INSTALL }} run publish -C .
   becomes
   run: ${{ env.HYPERCI_INSTALL }} run release -C .

3. Trailer. The gate now matches Release: true or Publish: true, case-insensitive on the key. The header comment at the top of ci.yml describes the old one:
   A push to main whose HEAD commit carries a Publish: true trailer
   becomes
   A push to main whose HEAD commit carries a Release: true trailer

4. CLI verb in the collision-guard error message:
   Ship past it with 'hyperi-ci publish --version X.Y.Z'.
   becomes
   Ship past it with 'hyperi-ci release --version X.Y.Z'.

5. Job name, optional. tag-and-publish / "Tag & Publish" reads oddly next to the rest. Renaming it changes the status-check name GitHub reports, so only do it if no ruleset here requires that check by name. main is unprotected on the repos I checked, but I have not checked this one.

WHAT IS NOT CHANGING

publish-target and the release tail's will-publish input keep their names permanently. GitHub validates reusable-workflow inputs before any of our code runs and hard-errors on an undeclared one, so a deprecation warning can never reach them.

ONE THING TO WATCH

This repo pins predict-version and setup-semantic-release at @main, so composite changes arrive on your next run with no action. That is what makes the drift silent: the composite moves, this workflow does not, and nothing fails until a name is actually retired.

Background: hyperi-io/hyperi-ci#149 for the rename, #151 for the dated removal of the JFrog-era keys.

Done when ci.yml reads will-release and run release, and the trailer and CLI references name release.

[catinspace-au]

Checked the caveat in item 5: main on this repo is unprotected (the branch-protection API returns 404), so no ruleset requires the tag-and-publish status check by name and renaming the job breaks nothing. Item 5 is safe to take.