ci(release): add a workflow_dispatch recovery path for an existing tag

[amondnet]

Problem

GitHub creates no push event for a tag beyond the third in one push. Pushing ten tags at once
during the Spring Boot 3.x backfill triggered zero release runs (verified: the same ten tags
landed on the remote, gh run list showed nothing; a subsequent push of exactly three triggered
three runs). A stranded tag has no recovery path — release.yml triggers only on tag push, and a
published tag is never deleted or moved, so the only options were deleting an unpublished tag or
publishing a misleading +rebuild.N.

Change

workflow_dispatch with a required tag input. The tag stays the source of truth: the input only
names which tag to run, and release-mode.ts still decides whether that tag owes publish,
register, or nothing.

Resolving the tag once in a job-level env: TAG also fixes what the dispatch path would otherwise
get wrong — a dispatched run's github.ref_name is the branch it was started from, so:

• the checkout now takes ref: ${{ inputs.tag || github.ref_name }}; without it a dispatch would
  build the default branch's tree and publish it under a tag's name
• the concurrency group is keyed on the tag, so two dispatches don't share one group
• the five steps that read github.ref_name inherit the resolved value instead

For a push event inputs.tag is empty, so every expression falls back to the pushed tag and
behavior is unchanged.

Verification

• yaml.safe_load parses the file; on = [push, workflow_dispatch], job env resolves as intended.
• Behavior on the push path is unchanged by construction (same expression, same fallback), and the
  30+ release runs of this backfill exercised that path.
• The dispatch path cannot be exercised until this is on the default branch — workflow_dispatch
  is only offered for workflows present there. First dispatch will be boot-3.3.0-boot-3.3.9.

Follow-up (not in this PR)

Two release runs failed at the availability gate with fetch-upstream failed: The socket connection was closed unexpectedly when ~30 runs probed Maven Central concurrently. A re-run cleared both, but
artifact-availability.ts has no retry/backoff — worth adding before the next bulk backfill.

---

Summary by cubic

Adds a workflow_dispatch recovery path so an existing release tag that never ran can be triggered manually. GitHub creates no push event for tags beyond the third in one push, so a batch backfill strands every later tag with no run and no way to re-trigger it.

The tag stays the source of truth — the input only names which tag to run, and the workflow still decides what that tag owes. A dispatched run's github.ref_name is the branch it started from, so the tag is resolved once at job level and used for the checkout, the concurrency group, and every step that previously read github.ref_name. Push events leave the input empty, so that path behaves exactly as before.

^{Written for commit 211e4cb. Summary will update on new commits.}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}