fix(cron): route Telegram forum topics via message_thread_id, gate DM-topic heuristic (#52060)

[Tranquil-Flow]

What

Since #22773 (commit 4cc28aa3b), proactive cron deliveries to a Telegram forum topic inside a private chat land in General instead of the target thread. The cron deliver target is correct and last_status=ok; only the routing is wrong.

Root cause

The is_private_dm_topic heuristic added in #22773 synthesizes direct_messages_topic_id for any telegram:<positive_chat_id>:<numeric_thread_id> deliver target:

is_private_dm_topic = (
    platform == Platform.TELEGRAM
    and thread_id is not None
    and _looks_like_telegram_private_chat_id(str(chat_id))   # positive → True
    and _looks_like_int(str(thread_id))                       # numeric → True
)

This shape matches both genuine Bot API Direct-Messages topics and regular forum topics inside private chats — the heuristic cannot distinguish them. When it fires, direct_messages_topic_id is placed in route_metadata, and the Telegram adapter nulls message_thread_id in response, causing the message to fall back to General.

Fix

Replace the inference heuristic with explicit-signal gating:

• Route via direct_messages_topic_id only when the job origin or target explicitly carries a direct_messages_topic_id key.
• Everything else routes via thread_id → message_thread_id — parity with pre-Cron delivery to private DM topics broken after PR #22410 — send_message_tool.py missing three-mode routing #22773 behavior and with live reply routing.

Putting thread_id directly in route_metadata (not just the DeliveryTarget) is deliberate: gateway/delivery.py private-chat topic detection demands a reply anchor when thread_id is absent from metadata. Cron deliveries have no inbound reply anchor, so the metadata key bypasses that check and lets the adapter route via a plain message_thread_id.

Tests

Regression tests added in tests/cron/test_scheduler.py:

Test	Scenario	Expected routing
test_live_adapter_forum_topic_in_private_chat_routes_via_message_thread_id	Positive chat + numeric thread (forum)	message_thread_id, no direct_messages_topic_id
test_live_adapter_forum_topic_media_routes_via_message_thread_id	Same, media path	thread_id in media metadata
test_live_adapter_explicit_dm_topic_routes_via_direct_messages_topic_id	Explicit direct_messages_topic_id in origin	direct_messages_topic_id routing
test_live_adapter_forum_thread_fallback_records_delivery_error	Negative chat (supergroup forum) — unchanged	fallback error path

All tests fail on upstream/main (RED) and pass with the fix (GREEN). Full scheduler suite: 164 passed, 0 failures.

Scope

One logical change in cron/scheduler.py — no new dependencies, no delivery.py changes.

[kshitijk4poor]

Thanks for reporting and diagnosing this (#52060) — your root-cause analysis was spot on.

We went with a runtime-signal fix in #58165 rather than the explicit-key gate here. The gate in this PR keyed on target.get("direct_messages_topic_id") or origin.get("direct_messages_topic_id"), but no code path ever writes direct_messages_topic_id onto a cron job's origin or target (_origin_from_env in tools/cronjob_tools.py captures only platform/chat_id/chat_name/thread_id/user_id, and the deliver string carries no such key). So that branch was effectively dead — it fixed the forum-topic case by routing everything via message_thread_id, but dropped support for genuine Bot API channel Direct-Messages topics.

#58165 disambiguates with a real runtime signal instead: 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, falling back to message_thread_id otherwise. That fixes your forum-topic regression and makes genuine channel DM-topic cron delivery work.

You're credited in the #58165 body. Closing this in favor of it — thanks again!