#7719: fix(slack): thread replies with @mentions dropped in requireMention channels

## Problem Thread replies containing explicit `@bot` mentions in `requireMention: true` Slack channels are silently dropped. The bot never receives or processes these messages. ## Root Cause `markMessageSeen` (dedup cache) was called **before** the mention gate check in `prepare.ts`. When Slack fires both `message` and `app_mention` events for the same thread reply: 1. `message` event arrives first → fails `requireMention` check → **but still marks the message as seen** 2. `app_mention` event arrives with `wasMentioned: true` → **deduped by `markMessageSeen`** → silently dropped Net result: the user's @mention vanishes completely. ## Fix **Moved `markMessageSeen` to after mention gating** in `prepare.ts`: - Messages are only marked "seen" if they pass all checks (channel allowed, mention gate, etc.) - If a `message` event fails the mention check, it's NOT marked as seen - The subsequent `app_mention` event can then pass through with `wasMentioned: true` **Added `dedupeSlackInboundEntries`** in the debouncer flush: - Handles the case where both events pass through within the debounce window - Dedupes by `ts`, preferring the entry with `wasMentioned: true` ## Tests - 2 new test files, 5 tests covering the dedup logic and the mention-gate ordering - All existing tests continue to pass <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR fixes a Slack ingestion edge case in `requireMention` channels where a thread reply could be dropped if Slack emits both `message` and `app_mention` events: the first event failed mention gating but still marked the message as “seen”, causing the later `app_mention` to be deduped. The change moves the dedup-cache `markMessageSeen` call into `prepareSlackMessage` after allowlist/mention gating, and adds `dedupeSlackInboundEntries` during debounce flush to collapse multiple inbound events for the same Slack timestamp, preferring entries that were explicitly marked as mentioned. Tests were added to cover the mention-gate ordering and the dedupe preference behavior. One merge-safety concern remains: the debounce key currently includes a `senderId` derived from `user ?? bot_id`, which may differ between `message` vs `app_mention` events for the same underlying Slack message. If those events land in different debounce buckets, `dedupeSlackInboundEntries` won’t see both and the “prefer mentioned” behavior may not apply consistently. <h3>Confidence Score: 4/5</h3> - This PR is likely safe to merge, with one plausible edge case that could reduce the effectiveness of the new inbound dedupe. - The behavioral change (moving markMessageSeen after mention gating and adding an in-flush dedupe) is localized and covered by new tests. The main remaining risk is that `buildKey` derives `senderId` from `user ?? bot_id`, which may differ between Slack `message` and `app_mention` events for the same message; if so, the two events won’t be coalesced in the same debounce window and the new `dedupeSlackInboundEntries` preference logic won’t apply consistently. - src/slack/monitor/message-handler.ts <!-- greptile_other_comments_section --> _{(5/5) You can turn off certain types of comments like style [here](https://app.greptile.com/review/github)!} <!-- /greptile_comment -->