Summary

Fixes #8736

• checkInboundAccessControl() was reading dmPolicy directly from cfg.channels?.whatsapp?.dmPolicy (channel-level config), ignoring account-level overrides
• Changed to read from account.dmPolicy which is resolved by resolveWhatsAppAccount() with the correct hierarchy: accountCfg?.dmPolicy ?? rootCfg?.dmPolicy
• This is consistent with line 42 which already uses account.allowFrom (the correct pattern)

Impact: When a WhatsApp account has dmPolicy: "allowlist" but the channel-level default is dmPolicy: "pairing", unauthorized senders would incorrectly receive pairing codes instead of being silently blocked.

Test plan

• Added test case proving account-level dmPolicy: "allowlist" is ignored when channel-level is "pairing" (test fails before fix)
• Applied one-line fix: account.dmPolicy instead of cfg.channels?.whatsapp?.dmPolicy
• Test passes after fix
• Full CI gate passed locally (pnpm build && pnpm check && pnpm test)

Greptile Overview

Greptile Summary

This PR fixes WhatsApp inbound access control to respect account-level dmPolicy overrides by reading dmPolicy from the resolved WhatsApp account (resolveWhatsAppAccount) instead of directly from the channel-level config. A regression test was added to ensure that when a channel default is dmPolicy: "pairing" but an account overrides to "allowlist", unauthorized senders are silently blocked rather than receiving pairing codes.

This change aligns dmPolicy lookup with the existing pattern used for allowFrom (both now come from the resolved account), and keeps the rest of the inbound gating/pairing logic unchanged.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk.
• The change is a single-source-of-truth fix (switching dmPolicy lookup to the already-resolved account config), and it is covered by a focused regression test that would fail under the previous behavior.
• No files require special attention