fix(ci): re-run the Release PR half after a tag lands

[mogita]

Ticket

CHA-2963

Problem

A commit merged while a release run is in flight is gated out of the release-pr job, because a release is pending. Nothing re-runs that job once the tag lands, so those commits wait for the next unrelated push to master before they get a Release PR.

Solution

A release-pr-followup job that runs the same reversible half once more, gated on needs.release.outputs.release_created. By then the tag exists, so release-please has a release commit to stop its walk at and proposes exactly the commits that missed the window.

How to verify

1. Merge a feat: or fix: PR and merge the Release PR it produces.
2. While the release run is still in Tests, merge a second feat: PR.
3. After 🚀 Tag and release finishes, Release PR (after tagging) runs and opens a Release PR containing that second commit.

On every non-release push the job skips, because release skips and release_created is empty.

[mogita]

One substantial finding, inline.

[mogita]

[Substantial] The workflow-level concurrency group already covers the case this job describes, so on that path it has nothing to do.

release.yml:18-20 sets group: release-${{ github.ref_name }} with cancel-in-progress: false. A push that lands while the release run is in flight joins that same group, so its run goes pending and starts only after this run ends. By then the tag exists and release-please has flipped the merged Release PR from autorelease: pending to autorelease: tagged, so that run's own detect reports pending=false and its release-pr job opens exactly the Release PR this job opens. If several pushes land, GitHub keeps only the newest pending run, and release-please walks history, so the survivor still proposes every missed commit.

Put the other way round: detect cannot report pending=true for a commit merged during a release run, because the run that would report it cannot start until the release run is over.

What is left for this job is narrow and is not what the comment says: a push that produces no workflow run at all (a merge made with GITHUB_TOKEN, or [skip ci]), or a queued run whose detect step errors before it can set an output.

Either drop the job, or keep it and rewrite the comment to name the case it actually covers.

[mogita]

Agreed, and verified against the docs before acting: a second run in the group is pending, and "any existing pending job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place". So the run that would report pending=true for a commit merged mid-release cannot start until the release run is over, and by then the label has flipped.

Dropped the job. The premise behind it was wrong, not just the comment: I had assumed those pushes execute and skip, rather than queue.

detect's gate still earns its place for the two cases that do reach it, the release run itself and a run following a release that failed after its Release PR merged, so that stays.

[mogita]

Closing: the job this PR adds is redundant, see the inline thread. The workflow concurrency group already covers the case, so a push during a release run queues rather than skipping release-pr.

Same removal is going out for stream-sdk-java in GetStream/stream-sdk-java#97, which is where the job first landed.