Greptile Summary

This PR fixes a duplicate message delivery bug in the Mattermost integration introduced in 2026.3.8 (#27744), where enabling both block streaming and threaded replies (replyToMode: "all") caused each response to be sent twice — once as a threaded reply and once as a top-level channel post.

The root cause was that createBlockReplyPayloadKey included replyToId in the deduplication key. When the block-streaming pipeline and the final-payload path each resolved a different replyToId for the same content, the two keys mismatched and the dedup check failed, resulting in a second delivery. Removing replyToId from the key is the correct fix: content identity (text + media) is what determines whether a payload is a duplicate, while threading destination is a delivery concern.

Changes:

• block-reply-pipeline.ts: removes replyToId from createBlockReplyPayloadKey; all downstream dedup paths (sendPayload, bufferPayload, hasSentPayload) now correctly ignore replyToId
• config-schema.ts: adds replyToMode: z.enum(["off", "first", "all"]).optional() to MattermostAccountSchemaBase so the setting is validated
• channel.ts: adds an explicit threading dock with resolveReplyToMode reading channels.mattermost.replyToMode (default "all")
• New block-reply-pipeline.test.ts and expanded tests in agent-runner-payloads.test.ts / monitor.test.ts provide solid coverage for the fix

Minor note: replyToMode is placed in MattermostAccountSchemaBase, meaning the config schema accepts it at the per-account level (e.g. channels.mattermost.accounts.myAccount.replyToMode). However, resolveReplyToMode only reads from the top-level channels.mattermost.replyToMode. A per-account value would pass schema validation but be silently ignored at runtime. This is consistent with how other fields in this file behave (e.g. blockStreaming) and appears intentional, but is worth documenting in the config reference so users are not surprised.

Confidence Score: 4/5

• Safe to merge; fixes a real duplicate-message bug with targeted changes and solid test coverage — one minor test clarity nit noted
• The core fix (removing replyToId from the dedup key) is logically correct and well-scoped. The schema addition is additive and non-breaking. The threading dock implementation is consistent with existing patterns and correctly defaults to "all". Test coverage for the dedup fix is thorough across three test files. Score deducted one point for the per-account replyToMode schema/runtime mismatch (field accepted in per-account config but runtime only reads top-level), which could silently mislead users who attempt per-account configuration.
• No files require special attention; the per-account vs. top-level replyToMode discrepancy in extensions/mattermost/src/channel.ts and config-schema.ts is worth noting in documentation but does not affect correctness of the bug fix.

_{Last reviewed commit: 3c07c19}

Both review comments addressed in d30e660:

1. Misleading test title: Renamed to "drops all final payloads when block pipeline streamed successfully" and added a comment explaining that hasSentPayload is unreachable because shouldDropFinalPayloads short-circuits to [].

2. Per-account replyToMode: resolveReplyToMode now reads from the merged account config via resolveMattermostAccount({ cfg, accountId }), so channels.mattermost.accounts.<accountId>.replyToMode overrides are honored. Also added replyToMode to the MattermostAccountConfig type definition.