Fixes #7186

Problem

In Telegram threaded mode, certain markdown-only inputs (e.g. >) render to empty HTML via markdownToTelegramHtml(). The empty string is then passed to bot.api.sendMessage(), which rejects it with a 400 error: "message text is empty". The reply is silently lost.

Fix

Instead of silently dropping messages when HTML is empty, this fix falls back to sending the original plain text:

• Extracts the fallback send logic into a reusable sendPlainFallback() helper (DRYs up the duplicated sendMessage call)
• When markdownToTelegramHtml() produces empty output, calls sendPlainFallback() instead of skipping
• Adds EMPTY_TEXT_ERR_RE to also catch edge cases where empty text slips past the static check at runtime
• If even the fallback text is empty, returns undefined gracefully

Changes

• src/telegram/bot/delivery.ts — Refactored sendTelegramText() with early empty-HTML fallback, shared sendPlainFallback() helper, and EMPTY_TEXT_ERR_RE error catch
• src/telegram/bot/delivery.test.ts — Added test: "falls back to plain text when markdown renders to empty HTML in threaded mode"

Tests

✓ falls back to plain text when markdown renders to empty HTML in threaded mode

All existing delivery tests pass.

Greptile Summary

This PR fixes a bug where Telegram threaded mode silently drops replies when markdown-only inputs (e.g., >) render to empty HTML via markdownToTelegramHtml(). The empty string caused Telegram's sendMessage API to reject with a 400 "message text is empty" error.

• Early empty-HTML detection: Adds a !htmlText.trim() check in sendTelegramText() to fall back to plain text before attempting the HTML send, avoiding the 400 error entirely.
• DRY refactor: Extracts the plain-text fallback logic into a shared sendPlainFallback() helper, eliminating the duplicated sendMessage call that existed in the parse-error catch block.
• Runtime safety net: Adds EMPTY_TEXT_ERR_RE to catch "message text is empty" errors at runtime in case the static check is bypassed.
• Graceful empty handling: When even the fallback text is empty, sendPlainFallback() returns undefined instead of throwing.
• Test added covering the specific scenario of > input in threaded (forum) mode.

Confidence Score: 5/5

• This PR is safe to merge — it adds a defensive fallback path for an edge case without changing normal behavior.
• The changes are minimal and focused: an early guard for empty HTML output, a DRY refactor of existing fallback logic, and a runtime safety net regex. The normal (non-empty HTML) code path is unchanged. The added test covers the specific bug scenario. I traced through the full execution path for both the early-return and catch-block fallback and found no issues.
• No files require special attention.

_{Last reviewed commit: 34548ee}