ci: trigger PR reviews from review label

[dbpolito]

Ticket

SKIPPED

Description

Move PR review triggering into the main review workflow so maintainers can request reviews with a review label while keeping the existing automatic PR review flow.

Checklist

Review Triggers

• Run reviews for non-draft internal PR lifecycle events.
• Allow maintainers to trigger the same review flow by applying the review label.

Workflow Cleanup

• Remove the separate issue-comment review entrypoint.

Validation

• Check that labeling a non-draft PR with review starts the review workflow.
• Verify that standard PR lifecycle events still trigger reviews for internal branches.

[kompassdev]

★★★☆☆

The label-trigger path (pull_request_target + labeled) will check out the wrong code.

.github/workflows/kompass-pr-review.yml:24 — When pull_request_target fires on a labeled event, actions/checkout defaults to checking out the base branch (main), not the PR's code. This is because GITHUB_SHA and GITHUB_REF point to the base ref for pull_request_target events.

The deleted comment workflow handled this correctly by fetching PR details and explicitly checking out the PR head. This workflow needs the same treatment.

Suggested fix for the checkout step:

- name: Checkout code
  uses: actions/checkout@v4
  with:
    repository: ${{ github.event.pull_request.head.repo.full_name }}
    ref: ${{ github.event.pull_request.head.sha }}
    fetch-depth: 0
    token: ${{ steps.token.outputs.token }}

Using head.sha instead of head.ref pins the exact commit and avoids race conditions if the branch is pushed to while the workflow is starting. Using head.repo.full_name ensures fork PRs are checked out correctly. fetch-depth: 0 preserves the full git history that the comment workflow had.

This fix is safe for the pull_request path too — explicit ref/repo values override the defaults, and the values are available in both event contexts.

[dbpolito]

The workflow-level checkout is intentionally the trusted base-repo checkout.

pr/review already performs gh pr checkout <pr-number> before it inspects local repository files, so this workflow does not need to check out the PR head itself. The initial actions/checkout is only there so the workflow can load local repo content like ./.github/actions/kompass-opencode-install from the trusted base branch.

If we changed the workflow checkout to ${{ github.event.pull_request.head.repo.full_name }} / ${{ github.event.pull_request.head.sha }} on the pull_request_target path, that local action would come from PR-controlled code instead of the base repo, which is exactly what this flow is avoiding.

So the intended sequence here is:

1. checkout trusted base repo
2. run local tooling action from trusted repo contents
3. invoke opencode ... pr/review
4. let pr/review load PR context and run gh pr checkout before reading PR files

Because of that, I don't think the suggested workflow-level PR checkout change is correct for this design.