GitHub action: pull_request_review (review body) is not a supported trigger event

Start in packages/opencode/src/cli/cmd/github.handler.ts, reading USER_EVENTS, REPO_EVENTS, SUPPORTED_EVENTS, and the event-name gate. Compare the existing comment-event handling with the documented event table and the pull_request_review payload described here. Done means submitted review bodies containing /oc are handled consistently, or the event table clearly documents that they are unsupported.

Summary

/oc or /opencode in a PR review body (Submit review → Comment / Request changes / Approve) cannot drive the
action: pull_request_review is not a supported event for the action, so a workflow that listens for it either
skips (with the documented if:) or fails (with an if: that matches the review payload).

Re-filing the request from #37867 (auto-closed for inactivity) and #2152 (closed for inactivity). The code path below is
as of dev d870e22.

The code path

packages/opencode/src/cli/cmd/github.handler.ts:

const USER_EVENTS = ["issue_comment", "pull_request_review_comment", "issues", "pull_request"] as const
const REPO_EVENTS = ["schedule", "workflow_dispatch"] as const
const SUPPORTED_EVENTS = [...USER_EVENTS, ...REPO_EVENTS] as const

and the gate that consumes it:

if (!SUPPORTED_EVENTS.includes(context.eventName as (typeof SUPPORTED_EVENTS)[number])) {
  core.setFailed(`Unsupported event type: ${context.eventName}`)
  process.exit(1)
}

pull_request_review is not in either list, and it is not in the docs' event table either. Its sibling
pull_request_review_comment (the inline diff comment) is supported — this is about the review body, a distinct
event.

Reproduction

on:
  pull_request_review:
    types: [submitted]

jobs:
  opencode:
    if: contains(github.event.review.body, '/oc')     # note: review.body, not comment.body
    # ... the usual opencode step

Submit a review whose body begins with /oc, and the job reaches the handler and fails with
Unsupported event type: pull_request_review.

One caveat that makes the difference between a skip and a failure: the documented job condition matches
github.event.comment.body, which is absent on a review payload — so a workflow using the documented if: is skipped
(no error, no action) instead of failing. Both outcomes are wrong, but only the review.body gate makes the failure
visible.

Why it matters

Approving and asking for the next step in one gesture is a natural reviewer action, and today it does nothing unless
the reviewer leaves a separate timeline comment. Both prior reports were closed automatically for inactivity rather
than declined on the merits — a maintainer engaged on #2152 ("Will include this use case") and the review-body case was
never implemented — so the request stands.

Suggested shape, if it is wanted

Add pull_request_review to USER_EVENTS with an action filter on submitted, and read the instruction from
review.body — the comment events (issue_comment, pull_request_review_comment) read comment.body, and a review
has no comment, so the equivalent field is review.body. If it is deliberately not supported, saying so in the event table would let a workflow
avoid firing a guaranteed failure.

Happy to test a change if a maintainer wants one.