code-review plugin exits green without posting: orchestrator awaits an async agent the Action never resumes

## Summary

The `code-review@claude-code-plugins` plugin never posts a review when run from the workflow that `/install-github-app` generates. The job exits **green** and produces no comment, no review, and no inline notes — so a silent no-op is indistinguishable from a clean review.

The cause is a lifecycle mismatch, not a permissions or configuration problem. The plugin's first step launches the eligibility check as an **async background agent**, the orchestrator schedules a wakeup and yields, and the Action terminates the session before that wakeup fires. The review itself never begins.

## Environment

- `anthropics/claude-code-action@v1`
- `plugin_marketplaces: https://github.com/anthropics/claude-code.git`
- `plugins: code-review@claude-code-plugins`
- Workflow generated verbatim by `/install-github-app`, only `permissions` and output flags changed (see below)
- Auth: `claude_code_oauth_token` via `CLAUDE_CODE_OAUTH_TOKEN`

## What happens

From a run with `show_full_output: true`, timestamps unmodified:

```
19:08:30 "text": "Async agent launched successfully. ... The agent is working in the
background. You will be notified automatically when it completes."
19:08:33 "text": "Waiting on the eligibility check before proceeding further."
19:08:34 "content": "Next wakeup scheduled for 19:10:00 (in 85s). Nothing more to do
this turn — the harness re-invokes you when the wakeup fires or a
task-notification arrives."
19:08:41 "No buffered inline comments" <- run ends, 79s before the wakeup
```

Terminal result:

```json
{
"subtype": "success",
"is_error": false,
"num_turns": 4,
"permission_denials": [],
"terminal_reason": "completed",
"result": "Checking PR #6 eligibility for review before proceeding with the full workflow."
}
```

The final `result` is the orchestrator's own narration of what it was *about to* do. Total runtime 44s. `Post buffered inline comments` then reports `No buffered inline comments`, and the job concludes `success`.

## Why this looks like the plugin's step 1

`plugins/code-review/commands/code-review.md` begins:

```
1. Launch a haiku agent to check if any of the following are true:
...
```

That instruction is fine in an interactive session, where the harness re-invokes on the task notification. Under the Action there is no next invocation — the process exits when the turn ends, so anything awaiting a background agent is lost.

## What it is not

Ruling these out, since they were my first two guesses:

**Not permissions.** The stock workflow ships `pull-requests: read` and `issues: read`. Raising both to `write` changed `permission_denials` from **28 → `[]`**, so the grant does matter — but the review still posted nothing, which is the run traced above.

In the interest of not overstating this: the earlier read-only run behaved differently rather than identically. It ran **29 turns over 6m25s with 28 denials** before ending silently, where the write-permission run ends in **4 turns and 44s with zero denials**. I can account for the second precisely; I cannot fully account for the first, and it may be a separate problem that the read-only grant provoked. The trace above is the one I am reporting.

**Not workflow validation.** A separate run *was* correctly skipped with `Workflow validation failed. The workflow file must exist and have identical content to the version on the repository's default branch.` — that is expected when a PR modifies the workflow, and is distinct from this report. The run quoted above passed validation.

**Not a missing review.** The `@claude` path works. Commenting `@claude review this PR` on the same PR, through the `claude.yml` workflow in the same repo with the same token, produced a full substantive review in 1m53s that posted correctly and found real defects. Only the plugin-driven `pull_request` path is affected.

## Reproduce

1. Run `/install-github-app` on a repo and merge the PR it opens
2. Open any pull request
3. `Claude Code Review` runs and concludes `success` with nothing posted

Add `display_report: true` and `show_full_output: true` to see the trace above; without them the run logs only a turn count and a denial count, which is what made this hard to diagnose.

## Suggested fix

Either would do:

- Have the plugin await its subagents synchronously rather than yielding to a scheduled wakeup, so a single turn completes the workflow
- Or have the Action keep the session alive while background agents are outstanding, rather than terminating when the orchestrating turn yields

Separately, and independent of the root cause: **a run that produces no review should not conclude `success`.** Silent success is the reason this went unnoticed through several PRs — "review found nothing" and "review never ran" are currently identical from the outside. A non-zero exit, or a posted comment saying the review was skipped and why, would make the failure visible.

## Suggested workflow template change

The generated workflow grants `pull-requests: read` and `issues: read`. Even after the lifecycle issue is fixed, those leave the reviewer unable to publish what it finds. `write` on both looks correct for a job whose entire purpose is to post a review.