Fixes #69926.

Brings WhatsApp to parity with Feishu, IRC, LINE, Telegram, and Nextcloud-talk by accepting a per-group allowFrom list on channels.whatsapp.groups.<jid> (and the matching account-scoped entry). A non-empty per-group allowFrom overrides (does not merge with) the channel/account-level groupAllowFrom for that one JID, while groups without an override keep the channel/account-level list. Empty arrays fall back to the channel/account-level allowlist.

ClawSweeper triage explicitly cleared this as "narrow, source-proven feature gap with clear files, tests, and boundaries."

Change

• WhatsAppGroupEntrySchema and WhatsAppGroupConfig gain an optional allowFrom: string[] (E.164 phone numbers).
• New resolveWhatsAppConversationGroupAllowFrom resolver in extensions/whatsapp/src/inbound-policy.ts, wired into resolveWhatsAppIngressAccess so the effective groupAllowFrom passed to resolveStableChannelMessageIngress reflects the per-group override for group conversations.
• The resolver respects the same multi-account inheritance guard as the rest of the WhatsApp config: account-scoped groups[<jid>].allowFrom takes precedence over a root-scope entry for the same JID, so root groups do not silently leak into accounts with their own groups map.
• bundled-channel-config-metadata.generated.ts regenerated to surface the new field in the bundled channel schema (verified via pnpm config:channels:check).
• docs/channels/whatsapp.md documents the per-group override semantics and shows a mixed-trust example.

Verification

• pnpm test extensions/whatsapp/src/inbound-policy.test.ts extensions/whatsapp/src/config-schema.test.ts -- 17/17 pass (6 new resolver cases + 2 new schema cases + existing schema tests).
• pnpm config:channels:check clean.
• pnpm exec oxfmt --check --threads=1 clean on every touched file.

Real behavior proof

Behavior addressed: operators should be able to express different sender allowlists per WhatsApp group (e.g. "Group A: any team member can drive the bot; Group B: only staff; Group C: only me") without dropping back to a single channel-wide allowlist. The runtime resolver should also honor the multi-account inheritance guard so root-scope per-group lists do not leak into accounts with their own groups map.

Real environment tested: local Linux 6.17 (Node 22.22.2). Live Node process driving the real production resolveWhatsAppInboundPolicy and resolveWhatsAppConversationGroupAllowFrom helpers from this PR (no mocks). The proof feeds the helper realistic OpenClaw configs (single-account, multi-account, override+inherit+empty cases) and prints the effective groupAllowFrom the inbound gate would apply.

Exact steps or command run after this patch:

node --import tsx /tmp/proof-69926.mts

Where /tmp/proof-69926.mts directly imports the production resolver helpers from extensions/whatsapp/src/inbound-policy.ts and validates per-group override, fallback on empty, account-scoped override, and inheritance behavior across seven scenarios.

Evidence after fix: terminal output captured directly from the live Node process exercising the production helpers.

--- channel-level only (single-account) ---
  group with per-group allowFrom override
    -> ["+15550003333","+15550004444"]
  group with a different per-group allowFrom
    -> ["+15550005555"]
  group WITHOUT override -> inherits channel-level
    -> ["+15550001111"]
  empty per-group allowFrom -> inherits channel-level
    -> ["+15550001111"]

--- multi-account: account-scoped groups override account-level groupAllowFrom ---
  work account, group has per-group override
    -> ["+15550007777"]
  work account, no override on this jid -> inherits work groupAllowFrom
    -> ["+15550008888"]
  personal account, no groups map at all -> inherits personal groupAllowFrom
    -> ["+15550006666"]

Observed result after fix:

• Group with a per-group allowFrom returns exactly that list, suppressing the channel-level groupAllowFrom for that JID.
• A different per-group entry returns its own list independently -- the override is per-JID, not channel-wide.
• A group without a per-group entry returns the channel-level groupAllowFrom, so existing configs keep working unchanged.
• An empty allowFrom: [] falls back to the channel-level list, so accidental empties do not silently fail closed for the group.
• In a multi-account config, the work account's per-group override applies for that JID, and groups without overrides correctly inherit the work account's groupAllowFrom rather than leaking from the personal account or the channel root.
• The personal account, which has no groups map of its own, falls back to its own account-level groupAllowFrom.

What was not tested: a live WhatsApp message ingress against a real WhatsApp Web account. The runtime proof above exercises the production resolver and resolveWhatsAppInboundPolicy chain, and the unit suite covers the schema acceptance plus the resolver semantics under every documented case, but neither runs a real inbound WhatsApp event against a paired account.