Slack connector: support controlled bot-to-bot triggering

[Yuyz0112]

Problem

The Slack connector cannot support bot-to-bot collaboration. When one Slack bot explicitly @-mentions another bot in a channel or thread, Slack delivers the app_mention event, but no job is created.

Both the app_mention and message entry points in channel-gateway/src/connectors/slack.ts skip any event carrying bot_id or subtype.

Proposal

Support a controlled bot-to-bot trigger: keep ignoring bot messages by default, and only process an app_mention when the sender is on a per-route trusted-bot allow-list and the current Slack app was explicitly mentioned.

Findings

• Those two returns are the only hard block. Downstream (dispatchJob, claimEvent, route client using the route owner's token) does not check whether the sender is a human or a bot, so the path works once they're relaxed.
• The route config column is jsonb and passed through untouched by the server, so no DB migration is needed.
• The require_mention=false auto-follow-up path is not affected as long as the message branch stays as-is.

Gaps in the naive implementation

1. No independent self-event filter. What currently blocks the bot's own replies is precisely the event.bot_id check. Once relaxed, self-identification must be written from scratch — and botUserId comes from web.auth.test(), which yields null on failure while only logging and continuing. That is fail-open; it must become "no identity → bot triggering disabled".
2. No loop brake. A mentions B, B's reply mentions A — an infinite loop. The messageTs idempotency only guards against redelivery of the same message and does nothing for newly generated ones; the per-thread serialization lock merely queues them up while burning tokens. A separate per-thread trigger rate cap is required.

Other implementation notes:

• Messages sent with a bot token usually carry no bot_message subtype; bot_id and app_id are the stable fields, and bot_profile is not guaranteed on app_mention. Validation should key off bot_id/app_id.
• dispatchJob uses event.user for template variables, which may be absent on bot messages — needs a fallback.
• Thread context labels every bot message as [bot], so an agent cannot tell multiple bots apart. Include the bot name.
• The route config form in the web UI rebuilds the config object from scratch on submit, so new keys must be added there or they are dropped on edit.

Suggested first version

1. Change the app_mention branch only; leave message untouched.
2. Add allow_bot_mentions (default off) and an explicit trusted_bots allow-list to the route config. No "allow all bots" option.
3. Validation order: exclude self (any of bot_id / app_id / user) → reject if botUserId is unavailable → match the allow-list and verify team_id.
4. Per-thread trigger rate cap; log to event_log when exceeded.
5. Fall back when user is missing; label bot names in thread context.

Roughly 3 files, 150–200 lines, no migration.