feat(webhooks): add webhook event dispatcher (#998)

[DSOTec]

Problem

The webhooks module already has subscription CRUD (#997), a delivery log endpoint (#1001), and a BullMQ delivery worker with HMAC signing + retries (#993/#1000). What's missing is the piece connecting the two: something that, when a domain event happens (e.g. tip.received), looks up the matching subscriptions and actually creates/enqueues a delivery. Without it, no WebhookDelivery rows are ever created and no HTTP delivery is ever triggered.

Solution

Adds dispatchWebhookEvent(ownerId, event, data) in backend/src/modules/webhooks/webhooks.dispatcher.ts:

• Looks up ACTIVE, non-deleted WebhookSubscriptions owned by ownerId that are registered for the given event type.
• Creates a PENDING WebhookDelivery row per match.
• Builds the documented envelope ({ event, timestamp, data }, see docs/WEBHOOKS.md) and hands it to the existing scheduleWebhookDelivery queue, which signs the payload (HMAC-SHA256) and delivers with retries — that path is untouched.
• One subscription failing to enqueue doesn't block the others (Promise.allSettled).

Also exports a WebhookEventType type from webhooks.schema.ts and WebhookEventEnvelope/WebhookDispatchResult types from webhooks.types.ts for use by callers.

Follow-up (out of scope here): delivery status (SUCCESS/FAILED) is not yet reconciled back onto the WebhookDelivery row after the HTTP call completes — that lives in the retry-policy worker (jobs/webhookDelivery.ts, #1000) and touching it felt like a separate, riskier change on an actively-changing branch. Rows are created as PENDING and the delivery itself is signed/sent/retried correctly; only the row's final status isn't updated yet.

Testing

• npx eslint src/modules/webhooks/*.ts — clean.
• npm run typecheck — no new errors (repo has 4 pre-existing errors in an unrelated notifications.test.ts parse issue on this branch already, untouched by this PR).
• npx vitest run src/modules/webhooks — 28/28 pass (23 existing + 5 new).
• npm run test (full suite) — same pre-existing failures as before this change (tests requiring a live Postgres instance I didn't have running locally), no new failures, 5 more passing than baseline.

Closes #998

[drips-wave]

@DSOTec Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Akanimoh12]

Great implementation