[FEATURE] Routines: filter `pull_request.review_requested` by requested reviewer (or expose it to the agent)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

A routine with a GitHub trigger on pull_request.review_requested cannot be scoped to "review was requested from me". The filter list is author, title, body, base branch, head branch, labels, is draft, is merged. Nothing on the trigger looks at requested_reviewer, even though GitHub includes it in the payload (https://docs.github.com/en/webhooks/webhook-events-and-payloads?actionType=review_requested#pull_request).

The agent can't work around it either. A fired session receives only this block, and nothing else from the webhook:

<github-trigger-context>
This routine was triggered by a GitHub webhook.
Event: pull_request.review_requested
Repository: org/repo
PR: #1234 — https://github.com/org/repo/pull/1234
Branch: feature/x → main
Head SHA: abc123...
...
</github-trigger-context>

No requested_reviewer, no sender. Asking the GitHub API for the PR's current requested reviewers doesn't help: when a coworker requests two people at once, both deliveries show both names.

This matters because GitHub sends one webhook per requested reviewer, not one webhook with a list. So when a coworker requests review from two people who each have this routine, every routine fires twice for the same PR, one second apart. I can see this in my run history today: two runs on the same PR at 06:52:11 and 06:52:12 UTC. The duplicate burns a run against the daily cap and, without extra machinery, produces a duplicate review.

This was previously requested in #65069, which went stale and was auto-closed without a maintainer response.

Proposed Solution

Either of these would solve it. The first is the clean one.

1. Add Requested reviewer (and Requested team) as filter fields on the pull request trigger, using the existing operators (equals, is one of, matches regex). A per-account convenience like "is me" would be ideal, since the routine already runs under a linked GitHub identity.

1. Failing that, include requested_reviewer.login (and sender.login) in the <github-trigger-context> block so the prompt can at least exit early when it isn't the intended reviewer. This still wastes a run per unwanted delivery, but it removes the need for external locking.

Alternative Solutions

What I do today: the prompt tries to create a lock file on a dedicated branch through the GitHub MCP file tools (create_or_update_file without a sha is create-only, so it's atomic) and exits silently if the lock already exists. It works, but it is a lot of prompt for what should be a checkbox, it costs an extra run per duplicate delivery, and it can't distinguish "requested from me" from "requested from someone else on the same PR".

The other workaround is to move the filtering into GitHub Actions: a workflow on pull_request: types: [review_requested] with if: github.event.requested_reviewer.login == '<me>' that POSTs to the routine's API trigger (/fire). That gives exact filtering but needs a per-person token in repo secrets, loses the automatic PR checkout, and puts routing logic in a second system.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

1. Two maintainers each have a "review PRs assigned to me" routine on the same repo, triggered by pull_request.review_requested.
2. A coworker opens a PR and requests review from both.
3. GitHub sends two review_requested webhooks. Each routine fires twice, so four sessions start for one PR.
4. With a "requested reviewer equals me" filter, each routine fires exactly once, for the request that was actually addressed to its owner.