Summary

When a Slack conversation is already bound to a thread, a successful messaging-tool send inside that thread can be recorded too loosely for later reply dedupe. That can make a later visible reply look like a duplicate of the earlier tool send even when the follow-up reply is part of the same thread-bound conversation lifecycle.

Impact

This shows up as inconsistent Slack thread continuity:

• a tool send into an existing thread can suppress or skew a later final reply
• visibleReplies: automatic can look inconsistent when a prior messaging-tool send happened in the same turn
• a thread-scoped send can be treated like a channel-wide send during reply suppression

Expected

A messaging-tool send into Slack thread T1 should only count as dedupe evidence for the same routed thread T1.

Actual

The current dedupe path can collapse a threaded send down to the channel target, so later replies can be suppressed as if the whole channel already got the response.

Likely cause

There appear to be two contributing problems:

1. implicit message tool sends do not always preserve the active session thread id in send telemetry
2. reply dedupe can fall back to channel-only target matching even when one side is thread-scoped

Regression coverage to add or keep

• preserve the active thread id for implicit threaded message sends
• dedupe only against the same Slack thread route, not the whole channel
• keep queued/followup reply delivery thread-aware
• avoid regressing Telegram topic/thread suppression behavior while tightening Slack matching