ci(v5.1): sync bot caller workflows with main

[heskew]

claude-code-action validates a PR's caller workflows against the default branch, so drifted copies on v5.1 fail the review check on v5.1-targeted PRs (v5.1 has been failing every review this way — e.g. #2319 today). Content matches #2328 — byte-identical to main once #2328 merges, so merge #2328 first, then this.

🤖 Generated with Claude Code

https://claude.ai/code/session_01S94XethbGXpAb4DRKMD4kt

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[cb1kenobi]

Reviewed 3cc4afd4 (base v5.1) — no issues found. This PR looks good, nice job!

Verified rather than assumed:

• The new ref is a real unification. The five callers previously pointed at different ai-review-prompts SHAs; they all converge on be549ad0, and the uses:@<sha> / ai-review-prompts-ref: pair stays in sync in every file — which is the whole point of the duplicated-SHA comment those files carry.
• ready_for_review is correctly paired with the upstream draft-skip. be549ad0's _claude-review.yml gates on github.event.pull_request.draft == false, and its own comment says "callers add ready_for_review to their trigger types". Without this trigger a draft flipped to ready would never get reviewed. The job if: still resolves correctly for the new action value.
• Dropping the model: claude-sonnet-5 canary is a genuine no-op. I fetched _claude-review.yml at be549ad0: the model input now defaults to claude-sonnet-5, so removing the override changes nothing. (effort defaults to xhigh with a 60 high / 1500 xhigh / * max ladder — the live run on this PR picked --effort high for a 32-line diff, so the laddering is working.)
• All three sibling PRs in this repo produce byte-identical workflow files (hashed the five files at each head). So the family lands one consistent state across main, v5.1 and v5.2.

On the red review / review check — expected, not a defect. It fails with Workflow validation failed. The workflow file must exist and have identical content to the version on the repository's default branch. Any PR that edits these workflows necessarily differs from the copy on the default branch, so claude-code-action self-validation fails on the PR and clears on merge; the action's own message calls this normal.

One operational consequence worth knowing: that comparison is against the default branch, not the PR's base. Merging the main PR first, then the v5.1/v5.2 ones, keeps the window short — otherwise the release branches sit red against main's older copy until main catches up. Since the resulting files are identical, this is purely about ordering.

Any other red checks here are integration/cluster tests, which a .github/workflows/-only diff cannot influence — pre-existing flake, unrelated to this change.

—
Generated by Barber AI

[kriszyp]

_{🤖 Reviewed with Codex}

[kriszyp]

_{🤖 Reviewed with Codex}