Claude Code Review check_runs silently abandoned, time out at GitHub's 2hr stale limit

## Summary

Across multiple PRs in our repo (Nurture-Bio/GenomeHub, private), the Claude Code Review check is created on the PR, sits in `status: in_progress` indefinitely, and is eventually closed by **GitHub's 2-hour stale-check timeout** (not the App). The check completes with `conclusion: neutral` and no comments — or, in some cases, with partial comments mid-review and then nothing further.

## Evidence

Nine recent check_runs across four PRs in the same repo, all with `App.slug: claude` / `App.owner: anthropics`:

| PR | SHA | Started (UTC) | Ended (UTC) | Duration | Conclusion | Comments posted |
|----|-----|-------------|-----------|----------|------------|-----------------|
| #28 | (success) | 2026-05-12 18:58:23 | 2026-05-12 19:07:04 | **8.7 min** | neutral | **4** (full review) |
| #33 | ef7cf04d | 2026-05-15 18:44:05 | 2026-05-15 20:44:07 | **2:00:02** | neutral | 0 |
| #34 | ef434245 | 2026-05-18 20:44:50 | 2026-05-18 22:44:56 | **2:00:06** | neutral | 0 |
| #34 | 85e1cd20 | 2026-05-19 00:33:20 | 2026-05-19 02:33:24 | **2:00:04** | neutral | 0 |
| #34 | 3b4b2c82 | 2026-05-19 18:10:28 | 2026-05-19 20:10:28 | **2:00:00** | neutral | 0 |
| #34 | 91ffa5de | 2026-05-19 19:15:46 | 2026-05-19 21:15:46 | **2:00:00** | neutral | 0 |
| #34 | 314c02b7 | 2026-05-19 20:21:36 | 2026-05-19 22:21:40 | **2:00:04** | neutral | 0 |
| #34 | 576ca022 | 2026-05-19 21:27:25 | 2026-05-19 23:27:28 | **2:00:03** | neutral | 0 |
| #34 | 6c6e5487 | 2026-05-19 22:33:20 | 2026-05-20 00:33:23 | **2:00:03** | neutral | 0 |
| #37 | ee657930 | 2026-05-26 17:22:29 | 2026-05-26 17:38:16 | **15.78 min** | neutral | **2** (partial) |
| #37 | a4038a1c | 2026-05-26 17:43:39 | 2026-05-26 19:43:40 | **2:00:01** | neutral | 0 |
| #38 | a1adc56 | 2026-05-27 22:42:19 | (in_progress, still as of writing) | — | — | 0 |
| #38 | 3c0a5d0 (empty commit retry) | 2026-05-27 23:48:07 | (in_progress) | — | — | 0 |

## Why this is the GitHub stale timeout, not an App timeout

- The end times consistently land at `start + 2:00:00 ± 0:00:06`. GitHub's documented behavior is to auto-stale check_runs with no update for **exactly 2 hours**.
- The `conclusion: neutral` matches GitHub's stale-out default rather than a deliberate App-side outcome.
- The App's `external_id` field on every run we've inspected (including the **successful** ones — PR #28, PR #37 first run) is **empty**, so that's just how this App always works and isn't a failure signal — withdrawing.
- PR #37 first run on `ee657930` succeeded (4 comments, 15.78 min). The second run on the very next commit `a4038a1c` (same PR, same repo, same diff scope plus one trivial commit) silently abandoned. Not a content/size issue.

## Additional symptom

The empty-commit retry on PR #38 (commit `3c0a5d0` at 23:34) took **13 minutes** for the App to even register the check_run (23:48:07). Webhook → check_run creation is normally seconds. This suggests significant backend queue latency.

## What we ruled out

- Not a config gap on our side. We don't have a workflow file for the App; the App's defaults work on small PRs, demonstrated by PR #28
- Not a permissions/installation issue. Check_runs are being created, partial comments do post on the runs that don't hang at zero
- Not a size limit. PR #34 (which silently abandoned 7 times in 24 hours) and PR #38 (this report) are in completely different size regimes
- Not deterministic by PR or by commit content. Same PR succeeded then failed on the next commit

## What we believe is happening

After receiving the `pull_request` webhook and creating the check_run, the App's review worker is crashing or hanging on initialization for a significant fraction of invocations. The check_run stays at `status: in_progress` indefinitely until GitHub's 2-hour stale-check timer expires and closes it with `neutral`.

## Repro

Open a PR in a repo where the App is installed and the diff is more than a few files. Watch the check_run go in_progress and either complete normally within ~15 min OR stay in_progress for exactly 2 hours and then close `neutral` with zero/partial comments. With repeated commits the failure rate appears to climb over time.

## Asks

1. Confirm whether this matches a known issue
2. Surface a way for installers to see the App-side worker logs for our installation
3. Cause the App to set a clear failure state when its worker dies, so the check doesn't stay in_progress for 2 hours

No repository files, tests, or entry points are identified; begin by reproducing the reported pull_request webhook and check_run behavior in an installed repository. Compare successful and stale runs, then determine whether the worker failure can be surfaced as a clear check failure before GitHub's two-hour timeout.

Written by the indexing model from the issue text.