#17438: feat(whatsapp): add blockFrom support for sender blocklisting

## Summary Add `blockFrom` array to WhatsApp config that rejects matching senders before any other access control check. - **Problem:** No way to block specific senders while keeping `dmPolicy: "open"`. - **Why it matters:** Users running open DM policies (e.g. for lead generation) need to block specific numbers without switching to allowlist mode. - **What changed:** Added `blockFrom` to WhatsApp schema, types, account resolver, and access control. Blocked senders are rejected at the gateway level with zero token usage. - **What did NOT change:** No changes to existing `allowFrom`, `dmPolicy`, or `groupPolicy` behavior. ## Change Type - [x] Feature ## User-visible / Behavior Changes New optional config field `channels.whatsapp.blockFrom` accepts an array of E.164 phone numbers. Messages from blocked senders are silently rejected before any other access check. ## Backward compatible Yes - `blockFrom` is optional and defaults to undefined. <!-- greptile_comment --> <h3>Greptile Summary</h3> Adds `blockFrom` array to WhatsApp config for rejecting specific senders before any access control checks. The implementation correctly handles both direct messages and group messages by checking the sender's E.164 phone number against a normalized blocklist. - Types updated consistently across `WhatsAppConfig`, `WhatsAppAccountConfig`, and `ResolvedWhatsAppAccount` - Schema validation added with optional array of strings - Account resolution properly cascades from account-level to channel-level config - Access control logic correctly placed before all other checks (lines 77-91 in access-control.ts) - Comprehensive test coverage including channel-level, account-level, DM, and group scenarios <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with no identified risks - The implementation is straightforward, well-tested with 4 test cases covering all scenarios, follows existing code patterns exactly, and the logic is placed correctly in the access control flow. The feature is additive (optional field) with no breaking changes. - No files require special attention _{Last reviewed commit: 865b5e3} <!-- greptile_other_comments_section --> <!-- /greptile_comment -->