Verified this end-to-end — the post-cutoff API claims are real and the tests are genuine. Details below, plus one small bug and a few notes.

API verification (live docs, since 10.1 shipped a day ago):

• sendRichMessage, sendRichMessageDraft, and InputRichMessage all exist as described; the {"markdown": ...} payload shape and the draft params (chat_id/draft_id/rich_message/message_thread_id) match the reference exactly.
• Negative control: reverting telegram.py + prompt_builder.py to main while keeping the PR's tests → 16/21 rich tests fail (the 5 survivors are the assert-legacy-behavior ones). The tests exercise the new path for real.
• Regression sweep (format, thread_fallback, topic_mode, reply_mode, reply_quote, send_draft_format, send_path_health, stream_consumer*) green. The thread_fallback failures that show up when several telegram files run in one process reproduce identically on clean main — pre-existing cross-file order interference, not this change.
• The _compute_single_send_routing mirror is faithful to send()'s index-0 block, including the dm_topic_reply_to_off carve-out and the fail-loud delegation.

Bug (small): pool timeouts become non-retryable on the rich path. Legacy send()'s outer handler returns retryable=(is_connect_timeout or is_pool_timeout or not is_timeout) — with an explicit comment that an httpx pool timeout means the request was never sent and must not be silently dropped. _try_send_rich's transient branch computes retryable=(is_connect_timeout or not is_timeout), so a pool-exhausted rich send returns retryable=False and the message is silently lost. Suggest adding self._looks_like_pool_timeout(exc) to the disjunction.

Note: reply_to_message_id is undocumented on sendRichMessage. The documented reply param is reply_parameters; the legacy scalar was never documented for post-7.0 methods. It does work today — I checked the official server source (tdlib/telegram-bot-api Client.cpp): do_send_message parses replies via get_reply_parameters(query), which falls back to the legacy reply_to_message_id arg generically for every send method. So no functional issue against the official server, but it's an undocumented contract; reply_parameters: {"message_id": N} would be the spec-clean spelling and serializes through api_kwargs just as well.

Note: the "Telegram exposes no rich-edit method" comment is inaccurate. 10.1 added a rich_message parameter to editMessageText (it's in the changelog). Keeping edit-based streaming on MarkdownV2 is a perfectly reasonable scope cut, but the code comment / PR rationale should say "deferred" rather than "impossible" — and it means group (edit-based) streaming is upgradeable in a follow-up.

Note: extra.disable_link_previews doesn't apply on the rich path. sendRichMessage exposes no link_preview_options parameter, so users who set that flag will see previews come back whenever the rich path engages. Probably worth a sentence in the docs section (or passing skip_entity_detection when the flag is set, if that suppresses URL entity previews — untested).

Nit: _rich_message_payload's skip_entity_detection parameter is currently dead — no caller passes it.

Also: this implements #44428 (where the blocker discussed was the PTB 22.6 pin — the raw do_api_request route neatly sidesteps that); consider adding Fixes #44428 to the body so they link. The branch currently conflicts with main, but it's one trivial hunk (supports_code_blocks landed where RICH_MESSAGE_MAX_BYTES is inserted — keep both).

Cherry-picked onto our rollup branch (with that conflict resolved) and everything above ran against the live venv. Nice work on the fallback taxonomy — the no-resend-on-transient rule for finals vs. the latch-off for drafts is exactly the right asymmetry.

Heads-up: this went CONFLICTING after #41215 (dde9c0d19) landed on main — it added a supports_code_blocks = True class attribute to TelegramAdapter at the same spot where this PR adds RICH_MESSAGE_MAX_BYTES. It's the only conflict (single hunk in gateway/platforms/telegram.py); the other six files apply cleanly.

Resolution is keep-both:

    # Telegram message limits
    MAX_MESSAGE_LENGTH = 4096
    supports_code_blocks = True  # Telegram MarkdownV2 renders fenced code blocks
    # Bot API 10.1 Rich Messages cap the raw markdown/html text at 32,768
    # UTF-8 bytes. Content above this is sent via the legacy chunking path.
    RICH_MESSAGE_MAX_BYTES = 32768

Verified the merged result compiles with both attributes present — the two changes don't interact (supports_code_blocks is read by the markdown rendering path, not the rich-message send path).

Verified the follow-up commit (aa9c890) the same way as the original — negative control plus full suite against a current-main-merged branch. Summary: it resolves nearly everything raised here and in #44829's follow-ups, two items remain.

Verification:

• Negative control: the updated tests against the v1 implementation → 18/39 rich tests + 5 progress/stream-routing tests fail; with the new implementation all pass (39 + 33 + 7).
• Regression sweep (format, thread_fallback, topic_mode, reply_mode, reply_quote, send_draft_format, send_path_health, network, progress_edit_transient, stream_consumer×3): 440 tests, all green.
• Live-spec checks: the 32,768 limit is indeed characters (the bytes→chars fix is correct); reply_parameters is the documented reply param ✓; the PTB error shapes in _is_rich_capability_error (EndPointNotFound on 404, InvalidToken wrap) match PTB's real behavior — nice catch, my earlier suggestion of plain message-matching would have missed the InvalidToken wrap.

Confirmed fixed from the earlier review / #44829: reply_parameters ✓, send-side capability latch ✓ (and the draft latch narrowed so mid-stream parse 400s don't latch — an improvement over both earlier versions, since draft frames carry partial markdown), expect_edits threading ✓ (this is the right fix for the format-flip-on-first-edit hazard, and it's new relative to #44829), dropping return_type=Message ✓ (a post-delivery parse failure can no longer masquerade as a send failure — the negative control actually tripped over the old msg.get("result", {}) crash on None), flood-control + connect/network retry parity ✓.

Still open (1): pool timeouts remain non-retryable on the rich path. The final transient return is still retryable=(is_connect_timeout or not is_timeout). Root cause: this branch is based on a main snapshot that predates dc4de14 (#35664), so _looks_like_pool_timeout doesn't exist here and the branch's legacy path lacks the pool handling too — merging won't regress legacy (main keeps its version), but the rich path needs the mirror. After a rebase onto current main it's two lines: add is_pool_timeout = self._looks_like_pool_timeout(exc) next to the other classifiers, include it in the in-loop retry disjunction (a pool timeout is explicitly "not sent to Telegram", so in-place retry is duplicate-safe) and in the final retryable=. A rebase would also clear the #41215 supports_code_blocks conflict.

Still open (2): link_preview_options is not a sendRichMessage parameter. Checked the live method spec — its full parameter list is business_connection_id, chat_id, message_thread_id, direct_messages_topic_id, rich_message, disable_notification, protect_content, allow_paid_broadcast, message_effect_id, suggested_post_parameters, reply_parameters, reply_markup — and InputRichMessage only has html|markdown, is_rtl, skip_entity_detection. Unknown params are silently ignored, so the new payload["link_preview_options"] line is a no-op and extra.disable_link_previews users still get previews on the rich path. Options: drop the line and document the limitation, or pass skip_entity_detection: true when the flag is set (suppresses URL entity detection, which may be the closest spec-level equivalent — behavior worth a live test).

Cherry-picked onto our rollup branch (same single keep-both conflict, plus the two-line pool-timeout mirror since that branch has _looks_like_pool_timeout) — CI runs there will exercise it. Also: since #44829 carries v1 + its own follow-ups, the cleanest consolidation path may be rebasing this branch onto main and letting #44829 cherry-pick the result, as you suggested there.

Merged via PR #44829 — your commit was cherry-picked onto current main with your authorship preserved in git history (05b9c84), via rebase-merge. Excellent work: the endpoint shipped a day before you wired it, and the fallback design (permanent-vs-transient classification, no duplicate resends, routing parity) was careful and correct.

Three follow-ups were added on top during salvage:

1. Reply anchoring now uses reply_parameters per the sendRichMessage spec — the reply_to_message_id scalar isn't documented on that endpoint, and the Bot API silently ignores unknown params, so replies would have quietly lost their anchor.
2. Final sends now latch rich off after an endpoint-capability failure (mirroring your draft latch), so old-PTB setups don't pay a failed roundtrip on every reply.
3. rich_messages ships default OFF for now — the endpoint is days old and we want live validation against a real bot before flipping the default on (your PR honestly flagged the same caveat). Flipping it to on-by-default is the planned follow-up once validated.

Thanks for the contribution!