fix(ci): give each dispatched release-images rebuild its own concurrency group

[muscariello]

Problem

Follow-up to #2159, which added workflow_dispatch to ci-release-images. Found while using it to rebuild the missing v3.0.1 images.

The concurrency group is keyed on github.ref:

group: ${{ github.workflow }}-${{ github.ref }}

For the tag-push trigger that is unique per release, so each tag gets its own group. For workflow_dispatch it is not: every dispatched run carries the ref of the branch the workflow is read from, so all of them land in a single group regardless of which tag they build.

With cancel-in-progress: false, GitHub keeps one run in progress and at most one pending; a further run displaces the pending one. Dispatching the three v3.0.1 rebuilds back to back therefore cancelled the middle one before it started:

run	tag	outcome
37436524603	slim-v3.0.1	in progress
37436537596	slim-control-plane-v3.0.1	cancelled while pending
37436550535	slim-channel-manager-v3.0.1	pending

All three reported head_branch=main, which is the collision.

Fix

Key the group on the tag being built, falling back to github.ref for tag pushes:

group: ${{ github.workflow }}-${{ inputs.tag || github.ref }}

Tag-push behaviour is unchanged. Dispatched rebuilds for different tags now run independently, while a repeat dispatch of the same tag still serialises, which is what you want when a rebuild is already pushing that tag.

Test plan

• actionlint and zizmor --offline clean
• Root cause reproduced in practice: the three dispatches above, all with head_branch=main
• After merge, dispatch two tags back to back and confirm both run