Advisory review: run for fork PRs when a maintainer applies the review label #462

Need

jepa-agent goes public soon (agentic-learning-ai-lab/jepa-agent#66). We want outside contributors' fork PRs to get the advisory review once a maintainer has looked at them, but not automatically on open.

On the caller side, agentic-learning-ai-lab/jepa-agent#95 does that. Open/reopen runs only for same-repo branches, and the review label runs for any PR, fork included. Adding a label needs triage access, so the label is the maintainer's approval.

advisory-review-agent.yml then skips every fork PR on its own. Both the session job (line 150) and the post job (line 285) require github.event.pull_request.head.repo.full_name == github.repository. A maintainer's label on a fork PR therefore never produces a review.

Proposal

Let a fork PR through both jobs when the triggering event is a label being applied:

if: >-
  github.event.pull_request.head.repo.full_name == github.repository ||
  github.event.action == 'labeled'

Callers already filter which label names trigger a review. A workflow input such as allow_labeled_forks: true (default false) would keep the current behavior for repos that don't opt in.

Things to keep right

• What the fork can reach. The session job holds the model API key and read-only tokens; the post job runs no model. So the exposure is the model key, through prompt injection in the diff. The label gate puts a human in front of that, but a spend cap on the reviewer keys would bound it too.
• Review the commit the maintainer saw. Today the PR head checks out as refs/pull/N/head, which can move if the fork pushes between the label and checkout. For label events, check out github.event.pull_request.head.sha (the head in the event payload), and have the post job re-check that the round stamp names that SHA.
• Header comment. The "same-repo PRs only" constraint in the header comment changes with this.

Acceptance

• A fork PR with the label applied gets one review of the labeled head SHA; opening or pushing to it triggers nothing.
• Same-repo behavior is unchanged.