[Feature]: Group isolation — per-chat scoping for webhooks and the read surface

Pre-flight

• I searched existing issues and this isn't already requested

Problem / motivation

OpenWA links a full WhatsApp account. Any API key or dashboard session that can reach a session can read every chat on it — DMs included. For a personal number there is no way to let a downstream agent/tool see only a specific set of groups.

Two concrete gaps today:

1. Webhook filters have no chat-id field. In src/modules/webhook/filters/filter-types.ts, FILTER_FIELDS.message exposes sender, recipient, body, type, isGroup, kind, fromMe, hasMedia, mentions. In a group, sender resolves to the participant (author), so kind: "group" selects all groups and cannot be narrowed to chosen JIDs. There is no chatId.
2. Filters only gate webhook dispatch. The read surface is not scoped either: GET /sessions/{id}/chats, /contacts, and /messages?chatId= return everything, and chatId on GET /sessions/{id}/messages is optional, so a bare call lists messages across all chats.

Use case: link a personal number, let an agent read only a curated set of groups, and keep personal DMs and all other groups off the wire. Today the only option is an external filtering proxy in front of the API.

Proposed solution

1. Add a chatId field to the message filter registry (kind id, operators is/isNot), resolving data.chatId ?? data.from. This looks like the documented extension point — one entry in FILTER_FIELDS.message, plus the dashboard MESSAGE_FIELDS list and one i18n key. Happy to open a focused PR for this part.
2. Longer term: a group-level scope alongside the existing session-scoped API keys (allowedSessions), enforced on the read surface (REST + MCP + dashboard). The repo already has route/query fence coverage machinery (global-route-fence-coverage.spec.ts, query-session-scope-coverage.spec.ts) that this could extend. Note the chatId-optional path on GET /messages would need handling (require chatId or filter the result set), and list endpoints (/contacts, /groups) can't 403 — they would need filtering rather than rejection.

Alternatives considered

• External relay: receive the webhook and re-serve only allowlisted groups. Works, but every consumer must be prevented from reaching the OpenWA API directly, and it duplicates a scoping concept the server already implements for sessions.
• Forking to add a per-endpoint guard. High upstream-maintenance cost, and easy to miss a surface (list endpoints, MCP).

Scope

• I understand some features are limited by the underlying WhatsApp engine.

Environment: main, self-hosted. WhatsApp engine: Baileys.