fix(cron): route Telegram forum topics via message_thread_id, support channel DM topics (#52060)

[kshitijk4poor]

Summary

Cron deliveries to a Telegram topic now land in the right thread — both ordinary forum-style topics in a private chat and genuine Bot API channel Direct-Messages topics.

Root cause: the #22773 heuristic classified any telegram:<positive_chat_id>:<numeric_thread_id> cron target as a Bot API channel Direct-Messages topic and routed it via direct_messages_topic_id, which makes the adapter null message_thread_id. A normal forum-style topic inside a private chat has the identical shape, so every such cron delivery landed in General instead of the target thread (#52060). It also meant the only way to address a genuine channel DM topic was this same ambiguous guess.

Changes

• cron/scheduler.py: new _is_channel_dm_topic() helper replaces the shape-based heuristic. It probes the live adapter's get_chat_info() once at delivery time and routes via direct_messages_topic_id only when the chat is actually a channel; everything else (private-chat forum topic, forum supergroup, group) and any probe error/timeout/None fall back to message_thread_id — parity with 0.16.0 and with live reply routing. thread_id is placed in route_metadata deliberately so the anchorless cron send bypasses the DeliveryRouter's private-chat reply-anchor requirement.
• tests/cron/test_scheduler.py: behavior-contract tests for forum-topic → message_thread_id, channel-DM-topic → direct_messages_topic_id (text + media each), plus two fail-safe paths (probe raises, probe returns None).

Validation

Check	Result
cron scheduler suite	211 passed
forum-topic test on main	RED (routes via direct_messages_topic_id — the bug)
forum-topic test with fix	GREEN (routes via message_thread_id)
E2E, real cross-thread event loop	forum→message_thread_id, channel→direct_messages_topic_id, raise/None/no-probe→fail-safe
Full _deliver_result E2E	correct metadata reaches adapter.send in both branches

Credit

Thanks to @Tranquil-Flow (#52079) for reporting and diagnosing #52060. This takes their idea — gate the DM-topic route rather than infer it from chat-id sign — and grounds it in a real runtime signal (get_chat_info chat type) instead of an origin key that no code path produces, so genuine channel DM-topic cron delivery works too.

Closes #52060

[alt-glitch]

This was generated by AI during triage.

Related: this is the active resubmission of the closed #52079 (both fix #52060). Competing OPEN fix: #55270 removes the is_private_dm_topic branch entirely and leans on the adapter's 400-thread-not-found fallback, whereas this PR probes get_chat_info() live and routes direct_messages_topic_id only for real channels (preserving genuine channel-DM-topic routing). Same underlying bug (#52060 / dup #55265). Flagging the cluster so a maintainer can pick one — the live-probe approach here looks the more complete of the two.