#7287: feat(whatsapp): expose group admin functions

## Summary Expose Baileys group admin functions in the WhatsApp channel plugin. ## Changes Add support for WhatsApp group administration actions: - `updateGroupSubject`: change group name - `updateGroupDescription`: change group description - `updateGroupPhoto`: change group profile picture - `updateGroupParticipants`: add/remove/promote/demote members - `updateGroupSettings`: toggle announcement/locked modes ## Implementation - **send-api.ts**: Added `GroupAdminMethods` type and 5 new methods wrapping Baileys functions - **monitor.ts**: Pass Baileys admin methods to sendApi - **outbound.ts**: Export public wrappers for each action - **whatsapp-actions.ts**: Action handlers with JID validation (`@g.us`) and try/catch error handling - **extensions/whatsapp/src/channel.ts**: Updated `listActions`, `supportsAction`, `handleAction` ## Config Enable with: ```yaml channels: whatsapp: actions: groupAdmin: true ``` ## Validation - Group JID must end with `@g.us` - Descriptive error messages on Baileys failures Closes #7244 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR exposes Baileys WhatsApp group admin operations end-to-end: the web inbound monitor now forwards additional socket methods into `createWebSendApi`, `send-api.ts` wraps them as IPC-safe methods, `src/web/outbound.ts` exports higher-level helpers, and `src/agents/tools/whatsapp-actions.ts` adds new action handlers with gating, group-JID validation, and error wrapping. The WhatsApp extension plugin (`extensions/whatsapp/src/channel.ts`) advertises and routes the new action names. Main issues found are around consistency and type-safety at the boundaries (extension action validation vs underlying handler requirements; missing types on forwarded Baileys wrappers; potential double-normalization of participant JIDs). <h3>Confidence Score: 3/5</h3> - Generally safe to merge, but there are a couple of boundary/typing issues that can cause user-facing validation regressions or type-check failures. - Core functionality wiring looks coherent and gated, but (1) the extension plugin’s `react` validation appears regressed (missing required `messageId` at the plugin boundary), and (2) the monitor forwards new Baileys methods without typing some parameters, which can fail strict TS or leak `any`. There’s also a potential JID normalization mismatch in the send-api wrapper that may cause incorrect participant JIDs depending on `toWhatsappJid` idempotence. - extensions/whatsapp/src/channel.ts, src/web/inbound/monitor.ts, src/web/inbound/send-api.ts <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->