fix(ci): cron timing doc + concurrency label-stuck race in copilot-review-fix.yml

Two issues caught by Copilot review on the parallel vuls-reach back-port
(vuls-saas/vuls-reach#22), addressed there in 821e3da. The same bugs
exist verbatim in the OSS copy of `copilot-review-fix.yml` (workflow
files were copy-portable across catalog/oss/vuls-reach in the recent
unification). Mirror the fix here so OSS doesn't ship the bugs.

1. **Stale "~5 min" cron-fallback claim** (lines 7-11): comment said
   "covers suppressed cases within ~5 min" but `copilot-clean-label.yml`
   actually uses `*/30` (cron fires every 30 minutes, worst case ~60 min
   — marker posted just after a tick stays fresh on the next tick).
   Updated to match the documented 30–60 min recovery window used
   elsewhere.

2. **`cancel-in-progress: true` race with label removal** (line 29):
   the first step on the labeled-PR path is "Remove copilot-review label
   if present" (so the label acts as a single-shot trigger). With
   `cancel-in-progress: true`, a new Copilot review/comment event for
   the same PR cancels the label-triggered run before that first step
   completes, leaving the label stuck on the PR. Re-adding an already-
   present label fires no event, so the manual retry path silently
   breaks. Switched to `cancel-in-progress: false` so queued events run
   sequentially; the marker-based dedup later in the job
   (`already_triggered` / `local_in_progress` jq passes) already prevents
   duplicate `@claude` posts, so queueing is the safe choice.

The same bugs exist in catalog (#223 already merged) — follow-up PR will
mirror the fix there.

Author: kotakanbe

.github/workflows/copilot-review-fix.yml

@@ -8,10 +8,14 @@ on:
   # (created) events are unreliable for the Copilot bot due to the agentic
   # architecture's GITHUB_TOKEN-driven event suppression. They are still listened
   # for as a best-effort fast path; the cron-driven fallback in
-  # `copilot-clean-label.yml` covers the suppressed cases within ~5 min.
+  # `copilot-clean-label.yml` covers the suppressed cases within ~30–60 min
+  # (cron fires every 30 minutes, worst case is "marker posted just after a
+  # tick" so cron only resumes on the tick after, ≈60 min later).
   #
-  # Multiple comments may trigger multiple events; concurrency cancel-in-progress
-  # ensures only the last one runs.
+  # Multiple events for the same PR are deduped by the marker-based check
+  # below (`already_triggered` / `local_in_progress` jq passes), so the
+  # concurrency group below uses `cancel-in-progress: false` and lets
+  # queued events run sequentially.
   pull_request_review:
     types: [submitted]
   pull_request_review_comment:
@@ -26,7 +30,15 @@ jobs:
   trigger-claude:
     concurrency:
       group: copilot-review-${{ github.event.pull_request.number }}
-      cancel-in-progress: true
+      # `cancel-in-progress: false` is intentional. With `true`, a new
+      # Copilot review/comment event can cancel a label-triggered run
+      # before its first step removes the `copilot-review` label,
+      # leaving the label stuck on the PR. Re-adding an already-present
+      # label fires no event, so the manual retry path breaks. Marker-
+      # based dedup later in the job (`already_triggered` /
+      # `local_in_progress`) already prevents duplicate `@claude` posts,
+      # so queueing is the safe choice.
+      cancel-in-progress: false
     # Run when: Copilot submits a review OR posts a review comment OR
     # 'copilot-review' label is added by the maintainer.
     # Only for same-repo PRs authored by kotakanbe (fork PRs cannot access