Key release concurrency on the commit, not the branch

[navjottomer]

Package

None — this is CI infrastructure.

What this fixes

Merging six package PRs in quick succession released one of them. The other four merged into main and never got a release, so nothing could install them, and there was no failure anywhere to say so.

d19161d1  #1 age-warning                    success
12f97835  #2 registered-users-only          cancelled
470e538a  #3 required-registration-fields   cancelled
926f46ff  #4 qr-code                        cancelled
0d2e01b2  #5 google-analytics               cancelled
833dc4e9  #6 digital-goods (external)       success

concurrency.group was release-${{ github.ref }}, so every push to main shared one group. GitHub keeps only the newest pending run in a group and cancels the rest — and a cancelled run takes its package's release with it, because detect works from that push's own github.event.before. The surviving run only releases what its own commit changed.

The failure is silent by construction: the merge succeeds, the run is "cancelled" rather than failed, and nobody learns the release is missing until an install comes up empty.

Changes

• Workflow level: group on github.sha. A push is its own unit of work and must never supersede another push's run.
• Release job level: new group on slug+version. This is the serialisation that was actually wanted — it stops two pushes touching the same package racing past the tag-exists check to create the same tag. cancel-in-progress: false, because the loser still has work to do.

Note on the four missed releases

Already recovered by re-running the cancelled runs one at a time — each replays with its own before SHA, and the leg is idempotent against an existing tag. All five in-repo packages now have releases and the catalog lists them. This PR is so it does not happen again.