fix(ci): add per-PR concurrency groups to SOP workflows (mc#1134)

SOP workflows were missing concurrency groups, causing queue storms
when comment bursts fired multiple simultaneous runs on the same PR.

Changes:
- sop-tier-check.yml:       add concurrency group (was missing entirely)
- review-refire-comments.yml: add concurrency group (issue_comment-only)
- sop-checklist.yml:         fix fallback to github.event.issue.number
                              for issue_comment on Issues (not PRs)

Fixes: mc#1134
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

.gitea/workflows/review-refire-comments.yml

@@ -9,6 +9,13 @@
 
 name: review-refire-comments
 
+# Cancel in-progress runs for the same PR to prevent stale status overwrites.
+# mc#1134: issue_comment bursts queued duplicate runs — one concurrency group
+# per PR prevents that while still allowing the no-op runs to finish quickly.
+concurrency:
+  group: ${{ github.repository }}-${{ github.event.issue.number }}
+  cancel-in-progress: true
+
 on:
   issue_comment:
     types: [created]

.gitea/workflows/sop-checklist.yml

@@ -69,8 +69,11 @@ name: sop-checklist
 
 # Cancel any in-progress runs for the same PR to prevent
 # stale runs from overwriting newer status contexts.
+# mc#1134: use || fallback — github.event.pull_request.number is null for
+# issue_comment on Issues (not PRs), but github.event.issue.number is always
+# set on issue_comment events.
 concurrency:
-  group: ${{ github.repository }}-${{ github.event.pull_request.number }}
+  group: ${{ github.repository }}-${{ github.event.pull_request.number || github.event.issue.number }}
   cancel-in-progress: true
 
 # bp-required: yes  ← emits sop-checklist / all-items-acked (pull_request)

.gitea/workflows/sop-tier-check.yml

@@ -41,6 +41,12 @@
 
 name: sop-tier-check
 
+# Cancel in-progress runs for the same PR to prevent stale status overwrites.
+# mc#1134: was missing entirely — comment bursts caused queue storms.
+concurrency:
+  group: ${{ github.repository }}-${{ github.event.pull_request.number }}
+  cancel-in-progress: true
+
 # SECURITY: triggers MUST use `pull_request_target`, not `pull_request`.
 # `pull_request_target` loads the workflow definition from the BASE
 # branch (i.e. `main`), not the PR's HEAD. With `pull_request`, anyone