Greptile Summary

This PR fixes a duplicate-message flash in Telegram DM preview streaming by switching the answer preview lane from native draft transport (sendMessageDraft) to real-message transport (sendMessage + editMessageText), matching how group/topic preview lanes already work.

Key changes:

• Introduces useMessagePreviewTransportForDm (scoped to dm + canStreamAnswerDraft) and applies it to both the answer and reasoning lanes, replacing the previous per-lane reasoning-only override. The answer lane was the source of the duplicate flash: its native draft required a materialize hop at finalize time, briefly producing two visible messages before collapsing back to one.
• Removes the now-unnecessary answerDraftStream.materialize call at finalize time; the final edit is done directly via editMessageTelegram on the already-real preview message.
• Tests updated: transport assertion is "message" for all DM lanes, materialize is asserted not to be called, and editMessageTelegram is asserted to be called with the preview message ID.
• Docs and CHANGELOG updated to remove sendMessageDraft/Bot API 9.5 references.

Confidence Score: 5/5

• This PR is safe to merge — the change is narrowly scoped, well-tested, and the root cause is clearly identified and addressed.
• The fix is logically sound: applying "message" transport to the answer lane in DMs mirrors the already-working group/topic path and eliminates the materialize hop that caused the flash. Tests cover all critical paths (transport selection, no-materialize finalize, edit-in-place). No regressions were introduced in adjacent lanes or non-DM scopes.
• No files require special attention.

_{Last reviewed commit: b65aa78}

Root cause note:

This PR exists because the remaining Telegram DM duplicate is not a normal double-send bug. It is the sendMessageDraft -> sendMessage handoff itself.

What we verified:

• #36746 improved cleanup by clearing the draft after materialize(), but that only fixes the stale copy case after the real message is already sent.
• The brief flash still happens because Bot API draft streaming has no documented atomic "commit draft as final message" step.
• The lower-level Telegram API has explicit draft-clearing semantics (clear_draft), but Bot API sendMessage does not expose an equivalent control.
• Major libraries (python-telegram-bot, aiogram, grammY wrappers/examples) mostly expose sendMessageDraft as a thin method; I did not find a documented no-flash finalization pattern built on top of Bot API.

So this change takes the pragmatic path: for Telegram DMs, keep preview streaming on a real message (sendMessage + editMessageText) so the final reply stays on the same message lifecycle and never crosses the draft materialization seam.

Manual repro after this patch: no duplicate flash across plain text and tool-use DM streaming cases.

I like this change just because the amount of issues we get about the "duplicate" send. I vote we revisit sendMessageDraft if/when telegram makes it less visually jarring.

Landed via temp rebase onto main.

• Gate: pnpm check hit an unrelated upstream TS error in src/agents/models-config.merge.test.ts after rebase; pnpm test -- src/telegram/draft-stream.test.ts src/telegram/lane-delivery.test.ts src/telegram/bot-message-dispatch.test.ts passed
• Land commit: 3456d64
• Merge commit: d4ab731

This PR trades native sendMessageDraft (typewriter-style smooth streaming) for sendMessage + editMessageText (chunked edits). While it does fix the duplicate flash on finalize, the resulting UX is noticeably worse — DM replies now update in visible blocks rather than streaming character-by-character like a real typing experience.

The original sendMessageDraft behavior was the closest thing to true real-time streaming on Telegram. The materialize flash was a minor annoyance (a brief duplicate that collapsed in <1s), but the fix effectively downgrades DM streaming to the same chunked-edit approach used in groups/topics.

Would it be worth exploring a fix that keeps draft transport but addresses the materialize hop specifically? For example, clearing the draft before materializing, or using a short delay to let the client reconcile. Losing the typewriter effect in DMs feels like a regression for users who valued the smooth streaming experience.

@yusnake if you can make a PR for it, I'll be happy to review it.

Drop a note in clawtribotors or telegram channel in discord if you can when the pr is compete. @yusnake