Automations cannot narrow GitHub PR triggers to specific actions #28

Context

Split out of Paca-AI/paca#605 at a maintainer's suggestion: GitHub-event handling belongs in this plugin rather than in the core's api_trigger, which is why the delivery-flood half of that report is now #27.

#27 stops the plugin from paying for events it does not handle (check_run was subscribed but never processed). What it does not solve is per-automation narrowing: "run my review automation when a PR is opened or commits are pushed to it, but not when someone adds a label."

Why it cannot be fixed in the plugin today

A plugin trigger declares an eventTopic in plugin.json, and the core dispatches automations purely on that topic — the trigger node's config is explicitly opaque to the core for plugin-contributed trigger types. So the plugin cannot see which automation is asking, and cannot apply a per-automation allow-list at emit time.

The current trigger set is therefore coarse:

• github.pr_linked — PR opened/reopened
• github.pr_state_changed — open/closed/merged transition
• github.branch_linked — branch created with a task reference

github.pr_updated is already emitted (carrying an action field, one event per linked task) but is not declared as a trigger in plugin.json — so the one topic that would let automations react to arbitrary PR activity cannot be bound at all.

Options

1. Declare github.pr_updated as a trigger. Cheap, and it removes the need for a core api_trigger + publicly reachable webhook. But it is the coarsest option: it fires on every PR action including labeled, edited, review_requested.
2. One topic per action (github.pr_opened, github.pr_synchronized, …). Precise, no core change, but it multiplies the trigger list and forces one automation per action, since a graph has a single trigger node.
3. A trigger-filter hook in plugin-sdk-go — the core hands the trigger node's config plus the event payload to the plugin, which answers match/no-match. Most expressive and keeps the GitHub taxonomy where it belongs, but it is an SDK + core change.

Option 3 is the one that actually matches the requirement; 1 and 2 are shims. Worth deciding on 3 before adding trigger types that would have to be deprecated afterwards.

Acceptance criteria (for whichever option)

• An automation bound to "PR activity" can be limited to a chosen set of actions.
• A delivery for an action outside that set creates no run.
• Existing triggers (pr_linked, pr_state_changed, branch_linked) keep their current semantics.