ci(pr-review): trigger OpenAB PR Review on PR events, not just cron

[chaodu-agent]

What problem does this solve?

OpenAB PR Review is a required status posted only by the */5 cron poller in pr-bot-review.yml. GitHub throttles scheduled workflows (observed: actual runs hours apart, not every 5 min), so after a push or rebase the new head SHA sits in "Expected — Waiting for status to be reported" for a long time, blocking the PR.

Change

Add a pull_request trigger so the review runs promptly on every head change:

on:
  pull_request:
    types: [opened, synchronize, reopened]
  schedule:
    - cron: '*/5 * * * *'   # kept as safety net
  workflow_dispatch: {}

Why this is safe (no other changes)

• Per-SHA dedup: the job already skips PRs whose current head SHA was already reviewed, so event-driven runs only review the PR that actually changed.
• Cron kept as a backstop (catches fork PRs where the event-triggered GITHUB_TOKEN is read-only and can't write statuses, plus anything missed).
• Concurrency left as-is (pr-review-poller, cancel-in-progress): for this repo (same-repo branches, low PR velocity) cross-PR cancellation effectively never happens; and cancelling a superseded same-PR review is the desired behavior (review the latest SHA).

Effect

A rebase/push now posts OpenAB PR Review within a minute or two instead of waiting on the throttled cron.

Note

For fork PRs, pull_request runs with a read-only token and can't write the status — those continue to be handled by the cron poller (which runs with full permissions). Same-repo PRs (the common case) post promptly.

[chaodu-agent]

LGTM ✅ — Minimal, safe trigger addition that eliminates cron-throttle latency for same-repo PRs.

What This PR Does

Adds a pull_request event trigger (opened, synchronize, reopened) to the cron-only review workflow so that OpenAB PR Review status is posted within minutes of a push/rebase instead of waiting on GitHub's throttled */5 cron schedule.

How It Works

Two-line addition to the on: block. The existing per-SHA dedup logic ensures no double-reviews, and the cron is kept as a safety net for fork PRs (where pull_request tokens are read-only).

Findings

#	Severity	Finding	Location
1	🟢	Clean minimal change — only touches the trigger, no logic changes	.github/workflows/pr-bot-review.yml
2	🟢	PR body clearly explains fork-PR limitation and concurrency tradeoff	—
3	🟢	Dedup via status check remains intact — no risk of redundant reviews	—

Finding Details

🟢 F1: Minimal, safe change

Only adds 2 lines to the on: block. No behavioral changes to the poll/review logic itself.

🟢 F2: Well-documented tradeoffs

The PR body explicitly covers fork-PR read-only token limitation and the global concurrency group behavior. Both are acceptable for this repo's usage pattern.

🟢 F3: Dedup preserved

The poll step already checks commit status state before triggering — a pull_request-initiated review that posts success/failure will be correctly skipped by subsequent cron runs.

Baseline Check

• PR opened: 2026-06-27
• Main already has: pr-bot-review.yml with schedule + workflow_dispatch triggers
• Net-new value: pull_request trigger eliminates multi-hour wait for status on push/rebase

What's Good (🟢)

• Smallest possible diff for maximum impact on developer experience
• Retains cron as backstop — no regression for fork PRs
• Clear, honest PR description with known limitations documented