fix(telegram): fallback blank rich previews

[artemgetmann]

Summary

• Problem: Telegram rich preview sends/edits can return a message id while the user-visible message text is blank.
• Why it matters: the tester-bot proof showed blank progress/answer preview bubbles even after fix(telegram): fallback blank rich final sends #1099 fixed the durable final-send path.
• What changed: rich preview send/edit now validates visible content and falls back to legacy sendMessage / editMessageText when Telegram reports blank rich output.
• What did NOT change (scope boundary): native rich draft transport still has no response body to inspect, and this PR does not change model behavior or TTS policy.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Related fix(telegram): fallback blank rich final sends #1099
• Related fix(telegram): make rich draft previews copy-safe #1118

User-visible / Behavior Changes

Telegram preview bubbles should no longer remain blank when the rich-message API returns an empty visible response; the preview path falls back to legacy text rendering.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: local worktree runtime
• Model/provider: not model-dependent for unit proof
• Integration/channel (if any): Telegram
• Relevant config (redacted): isolated tester bot @Artem_jarvis_email_bot

Steps

1. Run isolated Telegram runtime on codex/telegram-rich-final-transport-20260706.
2. Run pnpm openclaw:local telegram smoke reply-contract --json.
3. Observe blank preview bubbles in the userbot transcript before the late fallback final.

Expected

• Rich preview send/edit responses with blank visible content should not be treated as successful preview delivery.

Actual

• Before this PR, the preview lane accepted blank rich send/edit responses as delivered.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Failing live evidence before this patch:

• reply-contract artifact: .artifacts/telegram-smoke/20260708T105316Z-reply-contract-49d51303.json
• Transcript: messages 55115 and 55116 from @Artem_jarvis_email_bot had empty text.
• Runtime log showed preview/final activity around the failure and later plain fallback final:
  • final_send_completed ... textLength=65 ... result=delivered
  • telegram sendMessage ok ... message=1184 (plain)

Passing local proof after this patch:

• pnpm exec vitest run extensions/telegram/src/draft-stream.test.ts
• pnpm exec vitest run extensions/telegram/src/draft-stream.test.ts extensions/telegram/src/bot/delivery.test.ts extensions/telegram/src/send.test.ts extensions/telegram/src/bot-message-dispatch.test.ts
• pnpm build

Human Verification (required)

• Verified scenarios: blank rich preview send falls back to legacy send; blank rich preview edit falls back to legacy edit; existing final-send fallback tests still pass.
• Edge cases checked: visible rich response still stays on rich path; legacy edit fallback already covered.
• What you did not verify: live tester-bot rerun after this patch is still pending in PR CI/runtime lane.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert this PR.
• Files/config to restore: extensions/telegram/src/draft-stream.ts, extensions/telegram/src/draft-stream.test.ts.
• Known bad symptoms reviewers should watch for: duplicate blank rich preview plus visible legacy fallback message if Telegram accepts the rich preview but exposes it blank.

Risks and Mitigations

• Risk: Telegram may still create a blank rich preview before the fallback sends the visible legacy preview.
  • Mitigation: this PR prevents the blank rich response from being treated as success and keeps the stream's active message id on the visible fallback.