Problem

On PR #845, three stale "🤖 Claude Code Review — In Progress" comments accumulated over multiple CCR runs. Each had only the early checkboxes ticked; none reached "Complete". Two root causes in .github/workflows/claude-code-review.yml:

1. No workflow concurrency. Overlapping CCR runs each independently ran the "find existing sticky" search at the LLM step, and within the race window neither saw the other's just-created comment — so both created new ones.
2. No timeout cleanup. When the Claude job hit a timeout or runtime error after creating the sticky but before marking it Complete, the "In Progress" stub stayed forever. Pure prompt-level enforcement of "exactly one sticky" can't recover from this.

Fix

A. Workflow-level concurrency group

concurrency:
  group: claude-code-review-${{ github.event.workflow_run.pull_requests[0].number || github.event.workflow_run.head_branch }}
  cancel-in-progress: true

Ensures only one CCR run per PR is alive at a time. The replacement run finds the existing sticky and updates it in-place, so concurrency-cancellations don't leave zombies. head_branch fallback covers fork PRs where workflow_run.pull_requests is empty.

C. Post-step finalizer on failure
A failure()-gated step that queries for any "🤖 Claude Code Review" comments containing "In Progress" and PATCHes them to an "Aborted" body with a link to the failed run URL. Only true failures (timeout, API error, runner death) trigger it — concurrency-cancellations are deliberately excluded because the queued replacement run handles those.

Why not also B (pre-step ID resolution) and D (cleanup-at-start)?

A + C addresses the two observed failure modes. B and D were considered but skipped for now:

• B (resolve sticky ID in bash before LLM runs) reduces prompt-drift risk but adds complexity and a second source of truth for the ID. Punt unless A+C proves insufficient.
• D (delete duplicate stickies at start) is defensive against the same race A solves at the source. Redundant once A is in place.

Risks

• head_branch fallback collisions on fork PRs. Two fork PRs from different forks but with the same branch name would share a concurrency group. Worst case: one run cancels an unrelated PR's review, which then retriggers on the next push. Acceptable for a first iteration; the alternative (collapsing fork PRs into the same group) is no worse than the status quo.
• Finalizer race during concurrency cancellation. When run A is cancelled by run B, A's post-step could in theory run while B is updating the sticky. Mitigated by gating on failure() only — cancellation does not trigger the finalizer, so this race doesn't occur in practice.
• gh api -f body= multi-line handling. gh converts -f key=value to JSON for PATCH; multi-line shell variables embed real newlines that gh serialises as \n. Confirmed working in similar workflows; if a future GH CLI release changes this, the worst case is an ugly-looking aborted comment, not a workflow failure (the || true guards against errors).

Verification

• actionlint .github/workflows/claude-code-review.yml — clean.
• YAML parses (ruby YAML.load_file).
• Behaviour test (manual, post-merge): trigger a CCR run, push another commit before it completes. Expect: first run cancelled, second runs to completion, exactly one sticky comment.

Not in scope

• .github/workflows/sonar-pr-analyze.yaml does not post sticky comments, so it doesn't share this bug. No change needed.