#23251: fix(whatsapp): include LID in implicit mention detection for group replies

## Summary - **Problem:** In WhatsApp groups with \`requireMention: true\`, swipe-replying to the bot's message does not trigger a response. The reply is silently dropped. - **Why:** WhatsApp migrated to Linked Identity Device (LID) format (\`XXXX@lid\`) for user identities. When a user replies to the bot, the quoted message sender comes back in LID format. The \`applyGroupGating\` function only compared \`selfJid\` (\`@s.whatsapp.net\`) and \`selfE164\` against the reply sender — never the LID format. The comparison always failed. - **What changed:** (1) Extract \`sock.user.lid\` from the Baileys socket in \`monitor.ts\`. (2) Add \`selfLid\` field to \`WebInboundMessage\` type. (3) Compare \`selfLid\` against \`replySenderJid\` in the \`implicitMention\` check in \`group-gating.ts\`. - **What did NOT change:** Explicit @mention detection, E164 comparison, direct message handling. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #23029 - Related: #11758 (same root cause, explicit @mention variant) ## User-visible / Behavior Changes - Swipe-replying to the bot in WhatsApp groups now correctly triggers a response when the bot's identity uses LID format ## Security Impact (required) - New permissions/capabilities? \`No\` - Secrets/tokens handling changed? \`No\` - New/changed network calls? \`No\` - Command/tool execution surface changed? \`No\` - Data access scope changed? \`No\` ## Repro + Verification ### Steps 1. Configure a WhatsApp group with \`requireMention: true\` 2. Have the bot send a message 3. Swipe-reply to the bot's message without typing the bot's name ### Expected - Bot responds to the reply (implicit mention detected) ### Actual (before fix) - Reply silently dropped ## Evidence The bot's \`creds.json\` contains both identity formats: \`\`\`json "me": { "id": "1XXXXXXXXXX:1@s.whatsapp.net", "lid": "XXXXXXXXXXXX:1@lid" } \`\`\` The reply context returns the sender in LID format: \`\`\`json { "participant": "XXXXXXXXXXXX@lid" } \`\`\` Before fix, only \`selfJid\` (\`@s.whatsapp.net\`) was compared. After fix, \`selfLid\` (\`@lid\`) is also compared. ## Human Verification (required) - Verified scenarios: LID vs JID comparison logic, regex for stripping device suffix (\`:\d+\`) - Edge cases checked: \`selfLid\` is null/undefined (gracefully skipped in Boolean check) - What I did **not** verify: Live WhatsApp group test (no WhatsApp Business account) ## Compatibility / Migration - Backward compatible? \`Yes\` - Config/env changes? \`No\` - Migration needed? \`No\` ## Failure Recovery (if this breaks) If \`sock.user.lid\` is unavailable, \`selfLid\` is null and the new comparison branch is skipped — identical to pre-fix behavior. ## Risks and Mitigations Low risk. The LID comparison is additive (new \`||\` branch). If LID format changes in the future, the existing JID/E164 comparisons still work as fallback.