feat(gateway): bring Signal groups to Telegram parity (authz, mention, owner detection)

[sdugoten]

What & why

Brings a Signal group to Telegram-parity: any allowed member can talk to the bot, and the bot reliably knows which sender is the owner — without changing upstream's [name] sender prefix or any other platform's behavior.

Supersedes the draft #44706 (which makes only fix (1) below).

The fixes

1. Group-member authorization via SIGNAL_GROUP_ALLOWED_USERS — gateway/authz_mixin.py
_is_user_authorized's group-allowlist bypass only enumerated Telegram and QQBOT, so every Signal group sender fell through to the per-user SIGNAL_ALLOWED_USERS check and was rejected (Unauthorized user: <uuid> on signal). Adds Platform.SIGNAL: "SIGNAL_GROUP_ALLOWED_USERS" — the env platforms/signal.py already honors for its own group filter. (This is what #44706 does.)

2. Reply-to-bot counts as a mention — gateway/platforms/signal.py
With require_mention: true, quoting a message the bot itself sent now triggers a reply, no @mention needed (parity with Telegram/WhatsApp).

3. /slash commands bypass the mention requirement — gateway/platforms/signal.py
A message starting with / is handled without an @mention; command-level gating still decides which commands a non-owner may run.

4. Owner detection — gateway/platforms/signal.py, gateway/authz_mixin.py, gateway/session.py
Group senders arrive as a UUID while the owner allowlist holds a phone; the Signal adapter resolves UUID→phone via its number↔uuid cache and sets SessionSource.is_owner at intake. A generic _is_owner() fallback covers the DM path. Wildcard * is never an owner.

5. Surfacing the owner — gated, additive, no [name] change — gateway/run.py, gateway/session.py

• single-user sessions → an **Owner:** yes/no context line;
• cache-shared group sessions → keep [name] and prepend an owner-only [SYSTEM: sender NAME is the owner] marker (guests byte-identical to upstream).

Both outputs are gated to Platform.SIGNAL, so Telegram/Slack/Discord/etc. are completely unaffected. The gate is a source.platform in {...} set with a comment inviting other platforms to opt in once their adapter sets source.is_owner.

Scope notes

• The owner plumbing (_is_owner, the run.py marker, session.py is_owner) is shared with the WhatsApp PR feat(gateway): WhatsApp group authz + owner detection + reactions (fixes #7269) #53623; whichever merges first, the other's shared hunks become no-ops, and the gate set merges to {SIGNAL, WHATSAPP, WHATSAPP_CLOUD}.
• Owner-surfacing is gated, so no other platform's group/DM output changes.

How to test

.env: SIGNAL_GROUP_ALLOWED_USERS=*, SIGNAL_ALLOWED_USERS=<owner phone> (concrete, not *).
config.yaml: signal: { require_mention: true }.

1. A non-owner member @mentions the bot → it replies (previously Unauthorized user). (1)
2. Quote-reply to one of the bot's messages, no @mention → it replies. (2)
3. /help from a non-owner → handled; an owner-only / command from a non-owner → rejected. (3)
4. The owner's group messages arrive marked [SYSTEM: sender … is the owner]; everyone else plain [name]. (4,5)

Tests

New tests/gateway/test_shared_group_sender_prefix.py cases: owner gets the additive marker (Signal); guest stays plain [name]. All existing gateway prefix/session/signal tests pass under scripts/run_tests.sh (per-file isolation).

Platforms tested

macOS (Apple Silicon), signal-cli REST. Owner-surfacing + parity changes are additive/gated; non-Signal adapters unaffected.

Related

• Supersedes fix(gateway): authorize Signal group members via SIGNAL_GROUP_ALLOWED_USERS #44706
• Sibling of feat(gateway): WhatsApp group authz + owner detection + reactions (fixes #7269) #53623 (WhatsApp) — shares the (gated) owner plumbing
• Same root-cause class as the WhatsApp group-allowlist question in [Question] Whatsapp groups and require_mention: true, only reply to allowed users #7269

[alt-glitch]

This was generated by AI during triage.
Related: #52240 and draft #44706 both add only fix (1) (Signal in the group-authz dict). This PR is the broader superset — it includes that change plus mention-parity, /slash bypass, and owner detection. Not a duplicate; flagging the cluster so a maintainer can pick the canonical Signal-group-parity PR.

[teknium1]

Thanks for the broader Signal-group pass. The underlying authorization gap is real, but two parts need correction before this can be salvaged.

Problems

• The added Signal map entry still compares source.chat_id with the allowlist. Signal emits chat_id="group:<id>" at gateway/platforms/signal.py:607, while its allowlist contains raw IDs (:593-603) and the raw value is available as chat_id_alt (:709). Thus explicit configured groups remain unauthorized; only * works.
• The new reply-to-bot gate recognizes only quote authors equal to the account phone. Current Signal logic already resolves own replies through timestamps and UUID/phone mappings at gateway/platforms/signal.py:790-807; the new branch should use that path.

Suggested changes

• Match chat_id_alt (or normalize group:) and add authorization-path tests for explicit IDs, wildcard, and deny cases.
• Reuse _quote_references_own_message() and add UUID/timestamp reply tests. The current added tests cover only marker formatting.

Automated hermes-sweeper review.

[teknium1]

Signal's configured group IDs are raw, but the adapter sets source.chat_id to group:<id> and stores the raw ID in chat_id_alt. The existing comparison will therefore still reject every explicitly configured Signal group; match chat_id_alt or normalize the prefix here.

[teknium1]

Please use the adapter's existing _quote_references_own_message() path here. It also recognizes our sent-message timestamps and account UUID/UUID-to-phone mappings, while this comparison only accepts a phone-form quote author.