claude-agent-workflow's embedded re-dispatch omits --ref, so its review gate lands on the default branch

[d-morrison]

Deferred out of #1365, per
issue-first's
rule that a deferral is allowed provided it is tracked in the same breath.

The site

skills/claude-agent-workflow/SKILL.md:119, inside the documented claude.yml
post-step that re-dispatches a code review after the bot pushes commits:

gh workflow run claude-code-review.yml -f pr_number="$PR_NUMBER" || \
  echo "::warning::Could not dispatch claude-code-review.yml"

No --ref, so the dispatched run records against the default branch and its
require-review result never attaches to the PR --- the same defect #1365
fixes in three prose sites, and the reason #1361's cancellation was invisible.

Why it was deferred rather than fixed

The three sites #1365 fixed are prose instructions, where adding
--ref <PR-branch> is a self-contained edit. This one is executable YAML,
and getting it right needs a branch value in scope at that step. I did not
establish that one is available there, and guessing at a variable name in a
workflow snippet other repos copy is worse than leaving it flagged.

memories/github-actions.md:448 suggests the pattern exists
(PR_BRANCH: ${{ steps.pr_checkout.outputs.branch }} read for a
gh workflow run), so the fix is probably small --- but "probably" is the
reason this is an issue rather than a line in that PR.

What to check when picking it up

1. Whether steps.pr_checkout.outputs.branch, or an equivalent, is in scope in
   that step of claude.yml as the skill documents it.
2. Whether the same omission exists in the real claude.yml files across
   consumer repos, or only in this skill's documented snippet. The skill is a
   template, so a fix here does not reach an already-installed workflow --- and
   that gap is the more important half.
3. Whether Morrison-Lab/gha's own reusable workflow does the re-dispatch
   anywhere, in which case the fix belongs there instead, per
   dont-reinvent-wheel's
   note about patching a stale local copy of shared infrastructure.

A methodological note worth keeping

Sweeping for this with a line-oriented grep produced a false positive on
skills/refresh-claude-token/SKILL.md:199, which already carries --ref on a
continuation line:

gh workflow run claude-review.yml --repo <owner>/<repo> \
  --ref <branch> --field pr_number=<N>            # RUN_WORKFLOW

It nearly became a wrong "fix". That is the multi-line hazard
address-every-comment
already documents for this corpus's semantic line breaks, met on a shell
continuation rather than on prose --- so any sweep for this pattern needs to
join continuations before matching.