#4181: fix(whatsapp): resolve Brazilian mobile JID variants (8/9 digit)

## Summary Brazilian mobile numbers transitioned from 8 to 9 digits (adding a leading `9`) around 2012-2016. WhatsApp accounts created before the migration may still be registered internally with the **old 8-digit format**, causing silent message delivery failures. ## Changes ### `brazil-jid.ts` (new file) Resolver module that: - Detects Brazilian mobile numbers (`55` + 2-digit area code + 8/9 digit local) - Generates both 8-digit and 9-digit variants - Uses `sock.onWhatsApp()` to find which format is actually registered - Caches verified JIDs for 7 days to avoid repeated lookups ### `send-api.ts` - Optionally accepts `onWhatsApp` in the sock params - Calls the resolver before sending messages, polls, reactions, and presence updates - Falls back gracefully if `onWhatsApp` is not available ### `monitor.ts` - Passes `onWhatsApp` to `createWebSendApi` so the resolver can query WhatsApp ## Example | Input Number | Variants Checked | Resolution | |-------------|-----------------|------------| | +5511**9**99998888 | `5511999998888`, `551199998888` | ✅ Queries find correct one | ## Testing - Tested locally with Brazilian numbers in both formats - Confirmed message delivery to legacy 8-digit account - Cache stored at `~/.config/clawdbot/brazil-jid-cache.json` ## Logs ``` [brazil-jid] Checking variants for 5511999998888: [ '5511999998888', '551199998888' ] [brazil-jid] Found: 5511999998888 → 551199998888@s.whatsapp.net ``` Fixes #4168 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR adds a Brazilian WhatsApp JID resolver to handle legacy 8-digit vs modern 9-digit mobile numbers by generating both variants, probing `sock.onWhatsApp()`, and caching the resolved JID to disk. It wires the resolver into the outbound web send API so messages/polls/reactions/presence updates resolve the correct JID before sending, and passes `onWhatsApp` through from the monitor socket wrapper. Overall the approach fits the existing `createWebSendApi` abstraction by keeping the resolution local to outbound sends and falling back when `onWhatsApp` is unavailable. The main concerns are around correctness of the `onWhatsApp()` response handling and operational considerations of a per-user JSON cache written directly to a fixed config path. <h3>Confidence Score: 3/5</h3> - This PR is likely safe to merge, but has a couple correctness/operational edge cases worth addressing. - The change is localized to outbound WhatsApp send paths and is guarded when `onWhatsApp` isn’t available. However, the resolver’s assumption about `onWhatsApp()` result ordering can cause missed resolutions, and the new on-disk JSON cache introduces cross-platform path/atomic-write concerns that could lead to surprising behavior or cache corruption in multi-process use. - src/web/inbound/brazil-jid.ts <!-- greptile_other_comments_section --> _{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!} <!-- /greptile_comment -->