fix(whatsapp): honor group allowlist in bridge

[mgonto]

Summary

• pass WhatsApp group allowlist policy from the Python adapter into the Node bridge
• let explicitly allowlisted group messages pass the bridge without allowlisting every sender for DMs
• keep DMs and self-chat protected by the existing sender/self-chat gates
• align Node/Python group ID matching, including bare group IDs and wildcard allowlists

Test Plan

• node --check scripts/whatsapp-bridge/allowlist.js
• node --check scripts/whatsapp-bridge/bridge.js
• node --test scripts/whatsapp-bridge/allowlist.test.mjs
• python3 -m py_compile gateway/platforms/whatsapp.py tests/gateway/test_whatsapp_connect.py tests/gateway/test_whatsapp_group_gating.py
• python3 -m pytest -q tests/gateway/test_whatsapp_connect.py tests/gateway/test_whatsapp_group_gating.py

[tonydwb]

Code Review Summary

Verdict: Approved

Fix: Honor group allowlist in WhatsApp bridge

• Problem: Group IDs in the allowlist had to be specified with exact @g.us suffix, but the adapter sometimes received them without it, causing mismatches.
• Fix: _is_group_allowed now normalizes IDs by checking with/without @g.us suffix, plus support for bare group IDs and * wildcard.
• Environment variable support: Reads WHATSAPP_GROUP_ALLOWED_USERS env var in addition to config file. Passes both WHATSAPP_GROUP_POLICY and WHATSAPP_GROUP_ALLOWED_USERS to the Node bridge subprocess.
• Node bridge: Added matchesAllowedIdentifier() in allowlist.js that handles the same normalization logic in JavaScript.
• Tests cover bare group IDs, wildcard, and env var passthrough to the bridge.

---

Reviewed by Hermes Agent

[sukritgoyal]

Hey maintainers, can I be assigned on this? @tonydwb

[teknium1]

Thanks for identifying the group-scoped authorization gap. The underlying problem is still present on current main: scripts/whatsapp-bridge/bridge.js:637 applies the DM sender allowlist to external group traffic, and gateway/authz_mixin.py:467 only trusts an adapter group policy when no environment allowlist is configured.

Problems

• The adapter changes target deleted gateway/platforms/whatsapp.py; WhatsApp moved to plugins/platforms/whatsapp/adapter.py in 560010547.
• The proposed bridge fallback at scripts/whatsapp-bridge/bridge.js:350 would drop pairing DMs. Current main intentionally bypasses sender-list enforcement for WHATSAPP_DM_POLICY === 'pairing' at scripts/whatsapp-bridge/bridge.js:637.
• The proposed auth helper reads self.adapters directly at gateway/authz_mixin.py:192 in this PR. Current main's gateway/authz_mixin.py:34 resolves the adapter by SessionSource.profile; a salvage must preserve that multiplex isolation.

Suggested changes

• Port the adapter/test work to the bundled plugin and preserve the current pairing branch.
• Use _authorization_adapter(source.platform, source.profile) for the group authorization decision and add a profile-scoped regression test.

Automated hermes-sweeper review.

[teknium1]

A current-main port must retain the WHATSAPP_DM_POLICY !== 'pairing' guard before applying the sender allowlist here. scripts/whatsapp-bridge/bridge.js:637 deliberately forwards pairing DMs for the gateway pairing handshake; this unconditional fallback would drop them.

[teknium1]

Port this through current main's _authorization_adapter(source.platform, source.profile) rather than self.adapters. The current resolver is profile-aware, so direct lookup can read the default profile's WhatsApp policy for a secondary-profile message.

[eduardo]

I hit the same bridge-level failure on current main: the Node bridge applies the DM sender allowlist before Python can evaluate the configured group JID policy.

I opened #73465 as a narrow current-main salvage of this PR's bridge portion because this branch is now conflict-dirty and also carries gateway changes that have since moved/landed through adjacent work. The replacement is one commit touching only the three bridge policy/test files, and credits Martin Gontovnikas as co-author.