#6567: fix: include paired users in WhatsApp group sender allowlist

When `groupPolicy` is `"allowlist"`, the `groupAllowFrom` fallback only used explicitly configured `allowFrom` entries, not paired users from the pairing store. This meant users who paired via DM (the default flow) couldn't trigger the bot in groups unless they were also manually added to `groupAllowFrom`. ## Root Cause In `access-control.ts`, the `groupAllowFrom` fallback used `configuredAllowFrom` (config-only) instead of `combinedAllowFrom` (config + pairing store): ```ts // Before: const groupAllowFrom = account.groupAllowFrom ?? (configuredAllowFrom && configuredAllowFrom.length > 0 ? configuredAllowFrom : undefined); // After: const groupAllowFrom = account.groupAllowFrom ?? (combinedAllowFrom.length > 0 ? combinedAllowFrom : undefined); ``` ## Impact Users with default `dmPolicy: "pairing"` who set `groupPolicy: "allowlist"` had to either: - Set `groupPolicy: "open"` as a workaround - Manually duplicate every paired number into `groupAllowFrom` Now paired users automatically get group access when `groupAllowFrom` is not explicitly set. ## Files changed - `src/web/inbound/access-control.ts` — one-line fix to use `combinedAllowFrom` - `src/web/inbound/access-control.group-allowlist.test.ts` — 7 new tests covering group policy scenarios Fixes #6558 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes WhatsApp group `allowlist` behavior by changing the `groupAllowFrom` fallback in `src/web/inbound/access-control.ts` to use the combined allowlist (`allowFrom` config + pairing store) instead of config-only `allowFrom`. As a result, users paired via DM (the default flow) can now trigger the bot in groups when `groupPolicy: "allowlist"` and `groupAllowFrom` isn’t explicitly configured. The PR also adds a focused Vitest suite (`src/web/inbound/access-control.group-allowlist.test.ts`) covering `open`, `disabled`, and `allowlist` scenarios, including the pairing-store fallback case. <h3>Confidence Score: 4/5</h3> - This PR is safe to merge with low risk; it’s a targeted behavior fix with regression tests. - The functional change is a one-line fallback correction that aligns group allowlist behavior with existing combined allowlist logic, and it’s exercised by new unit tests. Remaining risk is mainly around config typing/coverage of edge cases (e.g., self-only defaults) rather than core logic regressions. - src/web/inbound/access-control.group-allowlist.test.ts (test robustness/typing) <!-- 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!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->