ci: update concurrency logic

[sudo-kraken]

Update to concurrency logic to avoid incorrect concurrency cancellations from multiple prs.

Checklist:

• I have read and followed the contribution guidelines.
• Disclosed any use of AI (see our policy)
• I have updated the documentation accordingly.
• All new and existing tests passed.
• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

Summary by CodeRabbit

• Chores
  • Standardized CI/CD workflow concurrency across pipelines: concurrency group keys now include workflow names and pull request identifiers where applicable. This provides finer-grained cancellation of in-flight runs, reduces accidental cross-workflow collisions, and improves pipeline reliability without changing build or test behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Concurrency group keys in 14 GitHub Actions workflow YAMLs were standardized to use ${{ github.workflow }} combined with either the pull request number (when available) or the git ref, replacing prior static or ref-prefixed group identifiers.

Changes

Cohort / File(s)	Summary
Workflow + PR number or ref .github/workflows/ci.yml, .github/workflows/codeql.yml, .github/workflows/cypress.yml, .github/workflows/docs-link-check.yml, .github/workflows/lint-helm-charts.yml, .github/workflows/renovate-helm-custom-hooks.yml, .github/workflows/test-docs-deploy.yml	Concurrency group changed to `${{ github.workflow }}-${{ github.event.pull_request.number
Workflow + ref .github/workflows/conflict_labeler.yml, .github/workflows/preview.yml, .github/workflows/release.yml, .github/workflows/stale.yml, .github/workflows/trivy-scan.yml, .github/workflows/helm.yml	Concurrency group changed to ${{ github.workflow }}-${{ github.ref }}, adding the workflow name to the per-ref grouping key.
Static to dynamic .github/workflows/docs-deploy.yml	Concurrency group changed from the static "pages" to ${{ github.workflow }}-${{ github.ref }}, making the group dynamic per workflow and ref.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Poem

🐰 I nibbled keys and tuned the flow,

Workflows hum where wild winds go,
PRs and refs now hold their place,
Each run snug in its own space,
Hooray — a tidy CI race! 🥕🐇

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'ci: update concurrency logic' accurately summarizes the main change across all modified workflow files—systematically updating concurrency group keys to use a standardized format incorporating workflow name and PR/ref information.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[cypress]

seerr    Run #3212

Run Properties:   Passed #3212  •  4939f13dbe: ci: update concurrency logic (#2481)

Project	seerr
Branch Review	develop
Run status	Passed #3212
Run duration	02m 13s
Commit	4939f13dbe: ci: update concurrency logic (#2481)
Committer	Joe Harrison
View all properties for this run ↗︎

---

Test results
Failures	0
Flaky	0
Pending	0
Skipped	0
Passing	31
View all changes introduced in this branch ↗︎

[sudo-kraken]

|| github.ref is only here for future proofing so just incase we add manual ttriggers etc it will not break the workflow run.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In @.github/workflows/conflict_labeler.yml:
- Around line 16-18: Change the concurrency.group expression so PR runs are
scoped by PR number instead of the base ref: update the concurrency.group (in
the concurrency block) to use github.event.pull_request.number as a fallback
before github.ref (e.g., use an expression that prefers
github.event.pull_request.number and falls back to github.ref) so
pull_request_target runs are isolated per-PR while push behavior remains
unchanged; keep cancel-in-progress: true unchanged.