claude-code-review.yml: enable track_progress for the review step

[jnasbyupgrade]

Summary

• The review step's prompt: input puts claude-code-action into automation mode, which by default posts nothing to the PR until the whole run finishes. Combined with the cost gate that waits for sibling CI, a review can look silently stuck for the better part of an hour with zero visible progress, indistinguishable from a hung job.
• Adds track_progress: true alongside the prompt: input in the "Run Claude Code Review" step so the action posts (and keeps live-updating) a tracking PR comment with a checklist as Claude works.
• Pattern modeled on Postgres-Extensions/cat_tools PR #69, which made the identical fix in its own claude-code-review.yml.
• Checked .github/workflows/claude.yml (the other Claude Code workflow, triggered by @claude mentions): it has no prompt: input, so it runs in the default interactive mode, not automation mode, and does not have this issue. No change needed there.

Follow-up fix: the review job was failing before it ever ran

track_progress: true above turned out to be moot on its own: the claude-review job has been failing on every recent PR (#10, #14, and this PR's own first run) for an unrelated, more fundamental reason — it never got past the checkout step. Confirmed from the actual failed run logs (gh run view <id> --log-failed on run 30940000508):

##[error]Refusing to check out fork pull request code from a 'pull_request_target' workflow.
This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache
scope, and runner access. Fetching and executing a fork's code in that trusted context
commonly leads to "pwn request" vulnerabilities. To opt in, review the risks at
https://gh.io/securely-using-pull_request_target and set 'allow-unsafe-pr-checkout: true'
on the actions/checkout step.

Root cause: actions/checkout shipped a breaking change (v4.4.0, backported to every major-version tag including v4 — see https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/) that added a new default-on refusal: checking out a fork PR's head/merge ref under pull_request_target is now blocked unless allow-unsafe-pr-checkout: true is explicitly set. Since our "Check out PR head" step intentionally tracks the @v4 tag (to pick up upstream fixes automatically), it silently picked up this new guard.

This isn't a case of the workflow being unsafe — it's that actions/checkout can't see the safeguards this workflow already has: the job's if: condition restricts the entire job to PRs from the trusted jnasbyupgrade fork only, and the checked-out code is only ever read (fed to the Claude review action), never built or executed. allow-unsafe-pr-checkout: true is the officially documented, conspicuously-named opt-in for exactly this already-mitigated case, so this commit adds it to the checkout step with a comment explaining why it's safe here.

The pull_request_target self-verification catch

This workflow runs on pull_request_target, which always executes the workflow file from the base branch (master), never the PR's own copy. That means this PR's own claude-review check will still run the old, broken workflow (pre-allow-unsafe-pr-checkout), since it reads from master, not from this branch — so this PR's own check is expected to keep failing at the same checkout step, even after this fix. That is not a sign the fix is wrong; it's a structural limitation of pull_request_target self-testing. Full verification requires merging to master and observing a subsequent PR's claude-review run succeed.

Test plan

• YAML syntax validated (python3 -c "import yaml; yaml.safe_load(...)")
• Confirmed claude.yml does not need the same fix (no prompt: input present)
• Root-caused the checkout failure from actual failed-run logs (not guessed) and cross-checked against actions/checkout's own release notes and GitHub's changelog post
• Verify track_progress behavior on a subsequent PR (cannot be verified on this PR itself, see above)
• Verify the checkout fix on a subsequent PR after merge to master (cannot be verified on this PR itself, see above)

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b2fb1f81-2dcd-4dc4-84ab-f5eba618d69d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[jnasbyupgrade]

Note on CI: the `claude-review` check is failing here, but it's a pre-existing issue unrelated to this change — it fails identically on other recent PRs (#10, #14) at the "Check out PR head" step, before the step this PR modifies ever runs:

```
Refusing to check out fork pull request code from a 'pull_request_target' workflow. ... set 'allow-unsafe-pr-checkout: true' on the actions/checkout step.
```

This is actions/checkout@v4 enforcing a newer security guard against checking out fork code under pull_request_target, even for the trusted jnasbyupgrade fork this workflow is gated to. It's orthogonal to the track_progress fix in this PR (which lives in the later "Run Claude Code Review" step, never reached). Flagging for visibility — separate fix, separate PR.

All substantive checks (the PostgreSQL 9.3–17 matrix and all-checks-passed) pass.