Slack: require_mention is bypassed for every reply in a thread whose root message mentions the bot

Bug

With a Slack channel configured as require_mention: true and thread_ttl: 0 ("always require @mention"), the bot still auto-replies to every reply in a thread whose root message @mentions the bot — including human-to-human messages that never mention it.

Root cause

In internal/channels/slack/handlers.go (handleMessage), the order of operations is:

1. For thread replies, fetchThreadParentContext fetches the thread root and prepends its raw text — mention tags included — to content:
   content = replyCtx + "\n\n" + content
2. The mention gate then runs on the combined string:
   mentioned := c.isBotMentioned(content)

Since isBotMentioned is a plain strings.Contains(text, "<@"+botUserID+">"), the parent's mention tag inside the quoted [Replying to …] block satisfies the gate for every reply in that thread, forever — regardless of require_mention and thread_ttl.

Reproduction

1. Slack channel instance with require_mention: true, thread_ttl: 0.
2. User A posts a channel message mentioning the bot: @bot @UserB please help with X (starts a thread).
3. User B replies in the thread without mentioning the bot: @UserA do you have more info?

Expected: the bot stays silent (no mention in the reply, thread auto-reply disabled).
Actual: the bot replies. Confirmed in production logs: the reply event reaches the agent (inbound: scheduling message) with no mention in its text.

Fix

Evaluate the mention gate on the event's own text (ev.Text) before any context injection. PR incoming that extracts the gate into a shouldRespondInGroup(eventText, channelID, threadTS) helper (thread-participation TTL behavior preserved) with table tests pinning the regression.

Start in internal/channels/slack/handlers.go at handleMessage, then trace fetchThreadParentContext and the mention-gate logic. Run or add the table tests for the shouldRespondInGroup behavior; done means an unmentioned reply stays silent when require_mention is true and thread_ttl is 0, while thread-participation TTL behavior remains intact.