claude-code-review: post an early PR-anchored comment linking the dispatched review run (so stalls are visible + runs are attributable)

[d-morrison]

Request

When claude-code-review.yml is dispatched (workflow_dispatch with a
pr-number input), post an early comment on that PR linking the specific
review workflow run — before the review model runs, not only on success.

Ideally the comment also states the pr-number it is reviewing and the head
SHA, then edits/appends the verdict when the run finishes.

Motivation (a real debugging incident)

On Morrison-Lab/ai-config PR #1194, an @claude review mention dispatched a
review that stalled (the review / claude-review job sat in_progress
with no progress for many minutes and never posted a verdict). Two things made
this genuinely hard to diagnose:

1. A stalled dispatched review leaves no breadcrumb on the PR. The reusable
   workflow posts its **Claude finished review** — [View run](…) comment
   only on success. When the job hangs, nothing is posted to the PR, so from
   the PR there is no link to the run and no sign a review was even attempted.
   (The claude.yml agent posts a :eyes: Picked up by workflow run #NNN
   ack, but that links the agent run, not the dispatched
   claude-code-review run.)

2. Dispatched review runs are indistinguishable by branch. A
   workflow_dispatch run records head_branch: main (the default branch),
   because the PR is passed as the pr-number input, not as the run's head.
   With two reviews dispatched in the same minute (#1173 and #1194), both runs
   show Claude Code Review | head=main@<same-sha> in gh run list, and the
   only way to tell which PR each is reviewing is to open the run and read its
   prompt/inputs. This directly caused a misattribution: a Ready for merge
   verdict from #1173's run was initially read as #1194's missing verdict.

An early PR-anchored comment (Review started — [run](…) reviewing #1194 @ <sha>) fixes both: a hung review is visible on the PR, and every run is
attributable to its PR from the PR side.

Relationship to existing issues

• ai-code-review: failover only covers dispatch failure, not a dispatched agent's runtime failure #362 — failover for a dispatched agent's runtime failure. Complementary:
  that issue is about detecting/recovering from the hang; this one is about
  visibility of the dispatched run while it is in flight (which also makes a
  hang obvious to a human even before failover kicks in).
• claude-review: embed the reviewed commit SHA in the review comment body #423 — embed the reviewed commit SHA in the review comment body. Same family
  (enriching the review comment); this asks for the comment to exist at
  dispatch time and carry a run link + pr-number, not only the SHA at the end.
• claude-code-review's workflow_dispatch re-review posts a successful require-review check tied to the wrong commit SHA #285 — the require-review SHA-attribution quirk shares the same root
  (workflow_dispatch runs recording against the default branch).