#15864: feat: add deliverOnlyToolMessages config for clean messaging channel replies

## Summary When enabled, the new `deliverOnlyToolMessages` option suppresses all assistant text output when the `message` tool sends to the originating channel. Only the message tool's output is delivered; any narration or intermediate text is discarded. ## Motivation Addresses #15856 — when running on messaging channels (Slack, Telegram, Discord), any text the assistant writes between tool calls gets delivered to the channel, even if the assistant later uses the `message` tool to send a proper response and ends with `NO_REPLY`. This creates "leaked" internal narration like: - "Let me check on that..." - "The sub-agent pushed the branch but hit a snag..." - "PR already exists — let me reply now." ## Solution The new `deliverOnlyToolMessages: true` config option: 1. Automatically disables block streaming (no text streamed during execution) 2. Relies on the existing `shouldSuppressMessagingToolReplies` logic to filter final replies when the message tool was used This gives users a single, explicit config option for clean messaging channel behavior. ## Usage ```yaml channels: slack: deliverOnlyToolMessages: true telegram: deliverOnlyToolMessages: true discord: deliverOnlyToolMessages: true ``` ## Changes - Added `deliverOnlyToolMessages?: boolean` to Slack, Telegram, and Discord config types - Added to corresponding Zod schemas - Updated dispatch handlers to disable block streaming when this option is enabled ## Testing - [ ] TypeScript compiles - [ ] Config validation works - [ ] Block streaming is disabled when option is set - [ ] Final replies are suppressed when message tool sends to originating channel Closes #15856 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR introduces a new per-account config flag `deliverOnlyToolMessages` for Slack/Telegram/Discord, adds it to the Zod provider schemas, and wires it into each channel’s inbound dispatch so block streaming is disabled when the option is enabled (to prevent “narration” text leaking into chat surfaces when the `message` tool is used). The main behavioral integration point is the `disableBlockStreaming` option passed into `dispatchInboundMessage` / `dispatchReplyWithBufferedBlockDispatcher`, relying on existing `shouldSuppressMessagingToolReplies` behavior to drop final assistant payloads when the message tool already sent to the originating target. <h3>Confidence Score: 3/5</h3> - This PR is close to mergeable but has at least one correctness/type-safety issue that should be fixed first. - The change is small and localized (config types/schemas + one additional condition in each channel dispatch), but the Telegram `disableBlockStreaming` computation uses `||` with a branch that can yield `undefined`, creating a mixed-type truthy chain that can lead to unintended `undefined` and inconsistent behavior or typecheck failures depending on downstream expectations. - src/telegram/bot-message-dispatch.ts _{Last reviewed commit: 209d0e7} <!-- greptile_other_comments_section --> _{(2/5) Greptile learns from your feedback when you react with thumbs up/down!} **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->