Telegram channel: set parse_mode for formatted messages

[wiselancer]

Summary

When ZeroClaw sends messages via the Telegram Bot API, it does not set the parse_mode parameter in sendMessage requests. This causes all formatting (bold, italic, code blocks, etc.) to be displayed as literal text rather than rendered.

Environment

• ZeroClaw version: 0.1.1
• Mode: daemon (with Telegram channel enabled)
• Model: openai-codex/gpt-5-codex

Steps to Reproduce

1. Configure ZeroClaw with a Telegram bot channel enabled
2. Send a message that triggers a response containing formatting (e.g., *bold*, _italic_, `code`)
3. Observe the Telegram message — formatting characters appear literally instead of being rendered

Expected Behavior

Messages should be rendered with proper formatting in Telegram. The sendMessage API call should include parse_mode set to MarkdownV2 (or HTML), so that Telegram renders bold, italic, code, etc.

Current Behavior

ZeroClaw sends messages without parse_mode, so Telegram treats the entire message as plain text. For example:

• *bold* appears as *bold* instead of bold
• `code` appears as `code` instead of code

Suggested Fix

Add a parse_mode field to TelegramConfig (defaulting to MarkdownV2) and include it in all sendMessage API calls:

[channels_config.telegram]
enabled = true
bot_token = "..."
parse_mode = "MarkdownV2"  # or "HTML"

Workaround

Adding a SOUL.md workspace file instructing the model to avoid formatting helps partially, but the model still uses *bold* and _italic_ which won't render without parse_mode.

[github-actions]

Thanks for opening this issue.

Before maintainers triage it, please confirm:

• Repro steps are complete and run on latest main
• Environment details are included (OS, Rust version, ZeroClaw version)
• Sensitive values are redacted

This helps us keep issue throughput high and response latency low.

[theonlyhennygod]

Implemented and opened PR: #2572

Root cause

• Streaming draft edits (update_draft -> editMessageText) sent plain text without parse_mode.
• Telegram therefore rendered markdown markers literally during streaming updates.

What changed

• Added shared edit payload builder for Telegram editMessageText requests.
• Updated update_draft to send HTML-converted content with parse_mode: "HTML".
• Reused the same helper for finalize_draft edit payload consistency.
• Added regression test asserting edit payload includes parse_mode: "HTML" and HTML-converted text.

Why this resolves it

• Draft edit requests now carry explicit parse mode and formatted payloads, so Telegram can render markup during streaming edits.

Validation highlights

• cargo fmt --all -- --check
• cargo test --lib update_draft -- --nocapture
• cargo test --lib edit_message_body_uses_html_parse_mode -- --nocapture

[theonlyhennygod]

Implemented on a dev-targeted branch and opened PR #2827.

Root cause

• streaming Telegram draft edits were not consistently sending a parse mode, so formatting behavior could differ from finalized message edits.

What changed

• added a shared Telegram edit payload builder with parse_mode: HTML
• applied it to both streaming update_draft and final draft edit paths
• added unit coverage for edit payload parse mode behavior

PR

• fix(telegram): set parse_mode for streaming draft edits #2827

Validation

• cargo fmt --all
• targeted Telegram draft/edit tests (all passing)