fix(whatsapp): honor dm_policy and group_policy open at the gateway

[Zyrixtrex]

What does this PR do?

The WhatsApp adapter gates inbound access at intake via its documented
config surface (dm_policy / group_policy / allow_from / group_allow_from),
but it never overrode enforces_own_access_policy. As a result the gateway's
_is_user_authorized() re-applied its env-only default-deny: when no
WHATSAPP_ALLOWED_USERS (or other allowlist) was set, a message the adapter had
already authorized (e.g. dm_policy: open, the documented default) was
dropped again at the gateway — so whatsapp.dm_policy: open and
whatsapp.group_policy: open did not actually work, and users saw a silent drop /
unexpected pairing prompt.

The fix declares enforces_own_access_policy = True on WhatsAppAdapter. This is
the exact drift-proof contract already used by WeCom, Weixin, Yuanbao, and QQBot
(introduced in #34515): the gateway trusts that an own-policy adapter authorized
the sender at intake and skips the env-only default-deny — while an explicit env
allowlist still takes precedence when configured. WhatsApp has the identical
config surface as those adapters and was simply missed when the flag was added.

No gateway logic changes were needed: _is_user_authorized() and
_get_unauthorized_dm_behavior() already read the flag / dm_policy generically,
so this is a one-line behavioral change plus tests and doc-string updates.

Related Issue

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• gateway/platforms/whatsapp.py — add enforces_own_access_policy property
  (-> True) to WhatsAppAdapter, matching the WeCom/Weixin/Yuanbao/QQBot pattern.
• gateway/platforms/base.py — update the enforces_own_access_policy doc-string
  to list WhatsApp among the own-policy adapters.
• gateway/run.py — update the _adapter_enforces_own_access_policy doc-string to
  list WhatsApp.
• tests/gateway/test_config_driven_access_policy.py — add WhatsApp to
  _OWN_POLICY_PLATFORMS, to the adapter-declares-the-flag parametrization, and to
  the env-clearing helper, so the real adapter's flag and the gateway's
  trust-without-env-allowlist behavior (DM and group) are both covered.

How to Test

1. Reproduce (before fix): configure WhatsApp with dm_policy: open and no
   WHATSAPP_ALLOWED_USERS / WHATSAPP_ALLOW_ALL_USERS. A DM that the adapter
   admits at intake is rejected at the gateway (_is_user_authorized() returns
   False → default-deny), so the user gets a silent drop / pairing prompt
   instead of a reply.

2. After fix: the same DM is authorized — the gateway trusts the adapter's
   intake decision. Setting WHATSAPP_ALLOWED_USERS still restricts access (env
   allowlist wins), and dm_policy: allowlist / disabled still gate correctly.

3. Automated:

   pytest tests/gateway/test_config_driven_access_policy.py \
          tests/gateway/test_whatsapp_group_gating.py \
          tests/gateway/test_unauthorized_dm_behavior.py -q
   

   All pass (79), including the new WhatsApp parametrizations.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run the affected tests and they pass (tests/gateway/test_config_driven_access_policy.py, test_whatsapp_group_gating.py, test_unauthorized_dm_behavior.py → 79 passed; full-suite parity is covered by Linux CI)
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — updated base.py / run.py docstrings
• I've updated cli-config.yaml.example if I added/changed config keys — N/A (no new config keys)
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A (no architecture change)
• I've considered cross-platform impact (Windows, macOS) — N/A (pure Python property; no platform-specific code)
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

[teknium1]

Merged via PR #37139 (commit 0cd5867 on main). Your commit was cherry-picked onto current main with your authorship preserved in git log. Thanks for the fix — same drift-proof contract WeCom/Weixin/Yuanbao/QQBot use, WhatsApp was simply missed when the flag was added.