[BUG] mcp__github__subscribe_pr_activity silently drops check_run completion events

Bug description

mcp__github__subscribe_pr_activity delivers the initial subscription-confirmation event but silently drops subsequent activity events (specifically check_run completions). This causes sessions that rely on webhook-driven wakeups to sit idle indefinitely.

Context

This was reported by two separate autonomous agent sessions (Claude Code on the web, Opus 4.7) on consecutive days. These are agent self-reports, not independently verified by a human. The human operator left both sessions running unattended, returned hours later, and found both had gone stale — either no webhook events arrived for CI updates, or the session received them but did not respond. The agents' own reliability reports describe the symptom as "no check_run completion events delivered," which is consistent with what the operator observed (idle sessions with CI long since finished).

1. Session 1 (2026-05-25): Seven webhook events arrived for review-comment replies and a Linear linkback comment within ~10 minutes of PR open. No webhook event arrived for any CI run completion. The agent fell back to polling via mcp__github__pull_request_read.
2. Session 2 (2026-05-26): Subscription-confirmation event and a linear-code[bot] linkback comment both arrived. CI check_run completion events (UI Kit, Platform Admin, Frontend jobs) never arrived. Session sat idle until the human operator intervened.

Both sessions used the same pattern: open PR, subscribe via mcp__github__subscribe_pr_activity, wait for CI. Both received comment-type events but zero check_run completion events.

Steps to reproduce (as observed by the agent)

1. Open a PR via mcp__github__create_pull_request
2. Subscribe to activity via mcp__github__subscribe_pr_activity for that PR
3. Observe that the subscription-confirmation event arrives (wrapped in <github-webhook-activity> tags)
4. Wait for CI check runs (in_progress at subscription time) to complete
5. No further check_run events arrived. Comment-type events (review replies, bot linkbacks) did arrive.

We cannot confirm whether this reproduces every time or only under specific conditions (session duration, remote execution environment, event volume, etc.).

Expected behavior

check_run completion events should be delivered to the session after subscribing, not just the initial subscription confirmation.

Observed behavior

• Subscription confirmation: Delivered.
• Comment-type events (review replies, linear-code[bot] linkbacks): Delivered.
• check_run completions: Never delivered. Sessions sat idle.

This pattern was consistent across both sessions — comment events work, check_run events don't.

Environment

• Claude Code on the web (remote execution environment)
• Model: Opus 4.7
• MCP tool: mcp__github__subscribe_pr_activity
• PRs under observation: Multi-workspace monorepo PRs with several parallel CI check_run jobs

Workaround

Polling with mcp__github__pull_request_read(method: "get_check_runs") on a timer instead of relying on webhook subscriptions.

Impact

Any agent workflow that uses subscribe_pr_activity to wait for CI events will stall silently. The session appears healthy — no errors, no timeouts — it simply never receives the check_run events it subscribed to.

Additional context

• Comment-type events pass through reliably; check_run completion events do not. This points to an event-type filtering or routing issue rather than a blanket delivery failure.
• May be specific to the remote execution environment.
• May be related to sub-agent boundaries — in one session, the sub-agent subscribed but the orchestrator (parent session) received the early events.