perf(ci): cancel superseded pull request runs

[BryanFRD]

Adds workflow-level concurrency so a second push cancels the first run instead of racing it, and so a burst of merges no longer produces a release per merge.

ci.yml calls FerrLabs/.github's reusable-ferrflow-release and had no group at all, which is what made this repository one of the three where a release could be interrupted. cancel-in-progress is conditional on purpose:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

Superseded pull request runs are cancelled. Pushes to main queue instead, which is the point: the release commit is pushed without [skip ci], so it starts another run of this workflow, and cancelling would kill the release that is still publishing. Queueing bounds a burst at one running and one pending release rather than one per merge, since GitHub keeps at most one pending run per group.

pr-title.yml keys its group on the pull request number. pull_request_target runs in the base's context, so github.ref is the base branch there and every open PR would otherwise share one group and cancel each other.

Workflows that publish are left alone: no form of cancellation is safe for them.

Ref FerrLabs/.github#321

[github-actions]

SonarQube — aucune nouvelle issue

_{Comparaison entre le projet bac à sable de cette PR et la branche par défaut : SonarQube Community n'analyse pas les PR, ce delta est calculé côté CI. Détail}

[ferrfleet]

Checked the four groups against each workflow's actual triggers.

ci.yml is the one that matters and it's right: github.ref is refs/pull/N/merge on pull_request, so PR runs get their own group and cancel cleanly, while refs/heads/main pushes and workflow_dispatch queue and never interrupt reusable-ferrflow-release. The release commit pushed back to main lands in the same group and waits rather than being killed, which is the behaviour the description claims.

pr-title.yml keying on github.event.pull_request.number is correct for pull_request_target — github.ref really would be the base branch there and collapse every open PR into one group.

Three nits inline, none blocking.

[ferrfleet]

Nit: same as renovate-rebase.yml, pull_request_target is the only trigger here so this is always true.

Suggested change

	cancel-in-progress: ${{ github.event_name == 'pull_request_target' }}
	cancel-in-progress: true

[ferrfleet]

Nit: pull_request is the only trigger on this workflow, so the condition is constant. Reads as if another event might reach it.

Suggested change

	cancel-in-progress: ${{ github.event_name == 'pull_request' }}
	cancel-in-progress: true

[ferrfleet]

Nit: this workflow has push: [main], schedule and workflow_dispatch, and all three resolve github.ref to refs/heads/main, so they now share one group and queue. GitHub keeps at most one pending run per group, so if two commits land on main around 06:00 the nightly scan can be cancelled while pending and silently skipped for the day.

Not a correctness bug (the push scans cover main too), but if you want the schedule to be independent of push traffic:

Suggested change

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

Cost is that a push scan and a nightly scan can run concurrently, which is harmless here.