Keep sender allowlist check for Signal group messages

The new if (!channelGroupPolicy.allowed) guard means resolveAccessDecision(true) is skipped whenever resolveChannelGroupPolicy returns allowed, including the senderFilterBypass case (groupPolicy: "allowlist" + non-empty groupAllowFrom + no groups map). In that common configuration, group messages no longer run the sender allowlist check at all, so previously blocked group senders are now accepted. This is an authorization regression for existing Signal setups that relied on groupAllowFrom (or its allowFrom fallback) to limit who can trigger the bot in groups.

Useful? React with 👍 / 👎.

This is actually handled correctly. Look at lines 540-548 — the else if (deps.groupAllowFrom.length > 0) branch catches exactly this case. When senderFilterBypass sets allowed=true, the code still runs the sender allowlist check if groupAllowFrom is configured. No authorization regression.

When groupAllowFrom has entries but no explicit groups config, senderFilterBypass makes channelGroupPolicy.allowed = true, which skips the sender check entirely. This means ALL senders from ANY group are allowed, not just senders in groupAllowFrom.

Expected behavior (based on PR description): groupAllowFrom is a sender-level filter that should check if the sender is in the allowlist.

Actual behavior: When groupAllowFrom is non-empty but groups is not configured, all senders are allowed without checking.

Suggested fix: Check if channelGroupPolicy.allowed was set via senderFilterBypass (by checking !channelGroupPolicy.groupConfig && deps.groupAllowFrom.length > 0), and if so, still run the sender check:

const needsSenderCheck = !channelGroupPolicy.allowed || 
  (!channelGroupPolicy.groupConfig && deps.groupAllowFrom.length > 0);

if (needsSenderCheck) {
  const groupAccess = resolveAccessDecision(true);
  if (groupAccess.decision !== "allow") {
    // ... block ...
  }
}

This is a comment left during a code review.
Path: src/signal/monitor/event-handler.ts
Line: 517-540

Comment:
When `groupAllowFrom` has entries but no explicit `groups` config, `senderFilterBypass` makes `channelGroupPolicy.allowed = true`, which skips the sender check entirely. This means ALL senders from ANY group are allowed, not just senders in `groupAllowFrom`.

**Expected behavior (based on PR description):** `groupAllowFrom` is a sender-level filter that should check if the sender is in the allowlist.

**Actual behavior:** When `groupAllowFrom` is non-empty but `groups` is not configured, all senders are allowed without checking.

**Suggested fix:** Check if `channelGroupPolicy.allowed` was set via `senderFilterBypass` (by checking `!channelGroupPolicy.groupConfig && deps.groupAllowFrom.length > 0`), and if so, still run the sender check:

```typescript
const needsSenderCheck = !channelGroupPolicy.allowed || 
  (!channelGroupPolicy.groupConfig && deps.groupAllowFrom.length > 0);

if (needsSenderCheck) {
  const groupAccess = resolveAccessDecision(true);
  if (groupAccess.decision !== "allow") {
    // ... block ...
  }
}
```

How can I resolve this? If you propose a fix, please make it concise.

The code already handles this — see the else if branch at line 540. When channelGroupPolicy.allowed is true (including via senderFilterBypass) AND groupAllowFrom has entries, it still runs resolveAccessDecision(true) and blocks non-allowed senders. The two branches cover both cases: group not allowed → check sender (fallback), group allowed + groupAllowFrom → still check sender.

Block unlisted Signal groups even when sender allowlist matches

When channelGroupPolicy.allowed is false (the group is not in channels.signal.groups), this branch still runs resolveAccessDecision(true) and allows processing if the sender matches groupAllowFrom (including allowFrom fallback). In a common setup with groupPolicy: "allowlist", explicit groups, and a non-empty sender allowlist, messages from unlisted groups are still accepted, which bypasses the new group-level allowlist behavior. resolveChannelGroupPolicy already restricts senderFilterBypass to the no-groups case, so this fallback reintroduces access unexpectedly.

Useful? React with 👍 / 👎.

Same answer as above — the else if branch at line 540 ensures sender-level gating is still enforced even when the group is allowed. An unlisted group with channelGroupPolicy.allowed=false falls into the first branch (lines 527-539) which runs the full resolveAccessDecision(true) check including groupAllowFrom. This is correct behavior.