Webhook source plugins — Stripe, GitHub, Linear

[dougwithseismic]

New webhook sources for:

• Stripe: payment events (subscription created, invoice paid, etc.)
• GitHub: repo activity (star, fork, issue, PR)
• Linear: issue events

Each source is a new audience who discovers Hogsend through their existing tools.

[dougwithseismic]

Confirmed we want this — presets are the fastest onboarding accelerant we have ("webhookSources: [stripe()] and payment events drive journeys on day one"). The open design work is the mapping layer, since raw payloads are easy but useless without it:

1. Identity mapping — which payload field resolves to the contact key per source (Stripe customer.email vs metadata.userId; GitHub sender.login has no email half the time). Preset options should let the consumer override the extractor: stripe({ contact: (p) => p.customer_email }).
2. Event naming — verbatim (stripe.invoice.paid) vs normalized (payment.succeeded)? Leaning verbatim-with-prefix so nothing is lossy, plus a small curated set of normalized aliases for the events journeys actually trigger on.
3. Curated subset vs firehose — Stripe alone has 200+ event types. Presets should default to a curated high-signal subset with an events: [...] opt-in for the rest, otherwise user_events fills with noise.
4. Signature verification per source — Stripe HMAC, GitHub X-Hub-Signature-256, Linear signing secrets — each preset owns its verification the way email providers own verifyWebhook, fail-closed when unconfigured.
5. Dedupe/replay — Stripe retries webhooks aggressively; presets need an idempotency key from the source event id so retries don't double-trigger journeys.
6. Where they ship — engine packages (@hogsend/source-stripe style) vs documented recipes. Leaning packages: typed options, testable, and each one is a docs/SEO surface.

Mechanically each preset is just a defineWebhookSource factory, so the per-source cost after the first one should be small.