WebhookTrigger: the one trigger kind #237 named that @workglow/triggers did not ship

[sroussey]

Split out of #237, which is now closed against delivered scope.

@workglow/triggers (300724d1d) shipped ITrigger, CronTrigger, PollingTrigger, IntervalTrigger and the Workflow.trigger() / .listen() surface. It did not ship a webhook trigger:

$ grep -rni webhook packages/triggers/src
(no matches)

Why it is a different shape from the three that shipped

The three existing triggers are all self-firing: they own a timer, decide when to fire, and need nothing from outside the process. A webhook trigger is externally fired — something else receives an HTTP request and has to hand it to the trigger. That means the interesting design questions are not in the trigger at all:

• Who owns the listener? A library cannot bind a port. The likely shape is that WebhookTrigger exposes a fire(payload) seam and the host (builder's Hono API, the Electron/Electrobun local API, a user's own server) routes to it — which makes this partly a @workglow/triggers change and partly a contract for hosts.
• Identity and authentication. A cron trigger cannot be fired by a stranger; a webhook one is reachable by anyone who learns the URL. Signature verification (the GitHub/Stripe X-Hub-Signature-256 shape) belongs somewhere, and "the host will handle it" is how it ends up handled nowhere.
• The payload is untrusted input and becomes run input. Whatever validates it should be stated, not assumed.
• Overlap policy interacts differently. The four policies at BaseTrigger.ts:499-513 were designed against a timer that can be delayed. An inbound request cannot be delayed — it can only be queued, rejected, or coalesced, and rejecting means answering the caller with a status code.

Not the same as #241

#241 is outbound webhook notification tasks — the workflow calling out. This is inbound — something calling in to start a workflow. They share a word and nothing else.

Suggested scope

1. WebhookTrigger in packages/triggers/src/trigger/, with a fire(payload, meta) entry point and no transport of its own.
2. A documented host contract: what a host must do to route a request to a trigger, and where signature verification sits.
3. One reference host binding (builder's api is the obvious candidate) so the contract is exercised rather than described.
4. Tests co-located under packages/triggers/src/**/__tests__/ — see the note on Triggers #237 about the existing six files sitting in packages/test.