#22675: feishu: move message dedup to just before dispatch

## Feishu: move message dedup to just before dispatch ### Summary Move the duplicate-message check in the Feishu extension from the start of `handleFeishuMessage` to immediately before the call to `dispatchReplyFromConfig`. This ensures messages are only marked as processed when we are about to hand them off to the agent, so that policy rejections and mid-flow failures do not block redelivery. ### Problem Previously, `tryRecordMessage(messageId)` ran at the very beginning of the handler. If the message was later rejected by policy (e.g. group not in allowlist, DM not paired, or group message without @mention), or if an error occurred before dispatch (e.g. media resolution), the message was already recorded as “processed.” When Feishu redelivered the same event (e.g. after WebSocket reconnect), the handler treated it as a duplicate and skipped it, so the message never reached the agent and appeared as “not received.” ### Solution - **Remove** the dedup check from the top of `handleFeishuMessage`. - **Add** the same check immediately before `core.channel.reply.dispatchReplyFromConfig(...)` for the main message. Dedup is now applied only when all policy checks have passed and the payload is built, so we only mark as processed when we are committed to dispatching. Any early return (allowlist, mention, pairing, etc.) or failure before that point does not record the message; redelivery will run the full flow again. True duplicates (same message delivered twice and both passing policy) are still deduplicated right before the single dispatch call. ### Testing - `pnpm test -- extensions/feishu/src/bot.test.ts --run` passes. - No changes to `dedup.ts`; the existing single-argument `tryRecordMessage(messageId)` API is unchanged. <!-- greptile_comment --> <h3>Greptile Summary</h3> This PR fixes a message deduplication timing issue by moving the dedup check from the handler entry point to immediately before agent dispatch. Previously, messages rejected by policy checks (allowlist, mentions, pairing) or mid-flow errors were incorrectly marked as processed, causing Feishu redeliveries to be silently dropped. The new placement ensures messages are only deduplicated when they successfully reach `dispatchReplyFromConfig`, allowing failed messages to be reprocessed on redelivery. Key improvements: - Dedup now occurs at line 948, right before the main dispatch call - Permission error notifications use a separate cooldown mechanism (unchanged) - Early validation returns (lines 575, 589, 616, 669) no longer prevent message redelivery - Media resolution errors caught at line 973 allow redelivery without dedup interference <h3>Confidence Score: 5/5</h3> - This PR is safe to merge with minimal risk - The change is a simple code relocation that fixes a clear bug without introducing new logic. The dedup mechanism remains unchanged, and the new placement is logically sound. Permission error notifications have independent cooldown protection. All existing tests pass, and the change improves message reliability by ensuring only successfully dispatched messages are marked as processed. - No files require special attention _{Last reviewed commit: 664f103} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} <!-- /greptile_comment -->