feat(webhook): smart pre-dispatch filters + WaId-aware contact matching

[tobiasstrebitzer]

Optional, additive pre-dispatch filters for webhook triggers. A webhook with no filters behaves
exactly as before (zero extra clicks, zero behaviour change). When filters are present, every
condition must match (AND) for the webhook to fire. Builds on the typed-WaId work from #374 (the
persistent lid -> phone table) and the Baileys sync hardening from #375.

Motivation

Webhook triggers fire on event type only (message.received, etc.). There are legitimate reasons to
pre-filter before delivery (Gmail-forwarding-style rules): only fire when sender = A, body contains
"invoice", it's a group, and so on. This cuts webhook congestion and over-emitting, and - in the age of
AI - controls token/cost downstream. message.* is the natural starting point; the design is
event-family aware so session/group can slot in later without touching the evaluator.

A second motivation is correctness of who a filter matches. WhatsApp addresses the same person
through several dialects (@c.us, @s.whatsapp.net, @lid), and a privacy-id (@lid) sender's number
isn't a phone at all. A naive JID compare silently misses the same contact across dialects, and misses a
lid-addressed sender entirely. This resolves ids through the typed-WaId layer + the persistent
lid -> phone table from #374, so a phone filter matches the person everywhere.

What ships

• Fields (message family): sender, recipient, body, type, mentions, isGroup, fromMe,
  hasMedia. Operators: is / isNot (ids, enums), contains / equals / matches (text, regex),
  with optional caseSensitive. Message-only conditions are skipped on non-message events, so a
  *-subscribed webhook still fires on session events.
• Engine-neutral contact matching (the WaId part). sender/recipient/mentions are matched by
  the neutral WaId key, not the raw JID. An engine-emitted id (any dialect, optional :device, a lid
  the table resolves to its phone) and a user-typed value (bare digits or a JID) both collapse to one
  neutral key. So a phone filter matches the person across @c.us / @s.whatsapp.net and any
  @lid that resolves to that phone - previously a silent miss.
• Persistence: a nullable filters JSON column on webhooks (portable migration: jsonb on
  Postgres, text on SQLite, idempotent hasColumn guard). Exposed as filters on the create/update
  DTOs and the response shape.
• Dashboard: a FilterBuilder UI on the Webhooks page (field/operator/value rows, a contact picker
  backed by a session-chats query, enum chips, regex/case-sensitive text). On the webhook list, the
  "N filters" badge opens a hover/focus popover summarising the configured conditions.

Commits

1. fix(dashboard): scope .modal-body label to direct children - unrelated CSS fix carried along.
2. feat(webhook): smart pre-dispatch filters - filters subsystem (family-aware field registry,
   evaluator, class-validator validation), entity column + DTO field + migration, dispatch wiring,
   FilterBuilder UI + badge popover + i18n, unit coverage + a new webhooks e2e suite.
3. feat(webhook): WaId-aware id matching via the lid->phone table - replaces raw-JID compare with
   WaId-neutral keys; injects the cross-session LidMappingStore into WebhookService and threads a
   lid resolver into the evaluator (which stays a pure function - resolver optional).

Key design decisions

• Composes with the existing delivery layer. Filters layer onto the current
  dispatch/withSafeFetch structure (fix(webhook): scope by-id ops and GET /webhooks to the session (close cross-session IDOR) #323/fix(security): pin outbound webhook and media fetches to the SSRF-validated IP #338/fix(webhook): deliver session lifecycle events and key them per occurrence #335) with no delivery-layer churn, preserving the
  SSRF IP-pin on both the direct and queued paths.
• WaId reuse, no new primitives. Matching reuses WaId.fromEngineJid / WaId.fromUserInput /
  .toNeutral() (src/engine/identity/wa-id.value.ts) - the same identity layer the engine and
  MessageService use. The dispatch-time resolver mirrors the adapter's resolvePhone
  (baileys-session-store.ts), backed by LidMappingStore.getCached.
• Optional dependency, no circular import. WebhookModule imports EngineModule (already exports
  LidMappingStoreService); the store is @Optional()-injected so unit/queue contexts work without it.
  Verified no circular dependency: the full AppModule boots in the e2e suite.
• Lean field set, no UI restructure. Hardens the existing fields rather than adding a separate
  User/Chat/Group taxonomy. The dashboard stores the neutral <digits>@c.us value; all dialect and lid
  normalisation happens server-side in the evaluator.

Acceptance / testing

• npm run build, npm run lint: clean.
• npm test: 1013 unit tests. Notable new coverage:
  • filter-evaluator.spec.ts: cross-dialect (@c.us vs @s.whatsapp.net), bare-number <-> JID,
    :device stripping, and a lid-resolution hit + no-resolver miss control (incl. mentions).
  • webhook.service.spec.ts: dispatch-level filter behaviour for every field/operator, plus an
    end-to-end lid sender resolves via the table -> phone filter fires (else a silent miss) test.
• npm run test:e2e: 26 (incl. the new webhooks.e2e-spec.ts: CRUD, auth, SSRF reject, HMAC on the
  wire, header sanitisation, and filter behaviour; booting it confirms no circular module dep).
• Dashboard: tsc -b clean, eslint src clean (only pre-existing warnings elsewhere), vite build
  clean.
• CHANGELOG [Unreleased] entry added.

Manual check (optional, Baileys)

Create a webhook with sender is <phone>. Have a group participant who is lid-only message in. With the
lid -> phone table populated (via #372 inbound capture / sync), the webhook now fires for that
participant - where a raw-JID compare would have missed them.

Non-goals / follow-ups

• No new filter fields and no FilterBuilder restructure.
• Reverse-direction lid matching (typing a raw @lid value to match a resolved @c.us) is out of scope
  • mirrors MessageService's forward-only resolution.
• session / group event families: the registry is ready for them; not wired in this PR.

[rmyndharis]

Thanks for this — the filter subsystem is genuinely well-built: the WaId-neutral contact matching, the portable jsonb/text migration, the validation wiring, and the test coverage are all solid. I'm holding it on one blocker before it can merge.

Blocker — ReDoS via the matches operator (remote event-loop freeze)

The matches operator compiles a user-supplied regex and runs RegExp.test() synchronously on the main event loop inside WebhookService.dispatch (filter-evaluator.ts safeRegexTest → webhook.service.ts dispatch filter), which runs on every inbound message. The isPotentiallyCatastrophicRegex heuristic only catches (X+)+-shaped patterns, and the length caps (MAX_REGEX_LENGTH=200, MAX_REGEX_INPUT_LENGTH=4096) don't bound the damage. Confirmed bypasses (heuristic returns false, then the loop freezes):

• (a|a)+b — alternation overlap, 7 chars → .test() against ~40 input chars ran ~91 seconds.
• .*.*.*.*x$ — polynomial → still running after a 30s kill against the 4096-char-truncated body.

Because webhook create/update isn't admin-gated, any API key that can manage a session's webhooks can plant such a filter; one inbound message body then stalls the entire process (all sessions, HTTP, queue) — a remote DoS.

A vm/timeout won't fix it (V8 doesn't interrupt a synchronous regex). Any one of these unblocks:

1. Drop the matches operator — contains/equals cover most needs; zero ReDoS surface, no new dependency.
2. re2 — linear-time, backtracking-free engine; keeps matches (adds a native dep).
3. worker_thread with a hard timeout — terminate a regex run that exceeds N ms.

Please also add tests for an alternation-overlap pattern ((a|a)+) and a polynomial one (.*.*.*x$) that assert either rejection at validation or a bounded evaluation time — the current single (a+)+ test passes while the real bypasses sail through.

Everything else looks merge-ready — happy to re-review as soon as the regex path is bounded.

[tobiasstrebitzer]

@rmyndharis kudos for spotting this, I agree on dropping regex/matches for now., keeps the filter path simple and easy to maintain - happy to revisit a linear-time engine like re2 later if regex demand shows up.

Validation now rejects the operator outright, and safeRegexTest plus the length caps and heuristic are gone, so no user-supplied pattern hits new RegExp() on the event loop anymore. Also pulled it from the dashboard FilterBuilder, the API client type, and the i18n keys across all 9 locales.