fix(gateway): preserve Telegram DM topic routing metadata in synthetic notifications

[kshitijk4poor]

Summary

Salvage of #34144 (@Dusk1e) onto current main, plus a hardening follow-up.

Synthetic gateway notifications — /update, /restart, shutdown warnings, and home-channel startup pings — built their Telegram send metadata inline as {"thread_id": thread_id}, bypassing the richer DM-topic routing metadata that normal replies carry. For Telegram private DM topic lanes, a thread-id-only payload with no reply anchor is rejected by the Bot API send path:

Telegram DM topic delivery requires a reply anchor; refusing to send outside the requested topic

so the notification was silently dropped (observed on /restart and home-channel startup).

What changed

• Centralize synthetic-send metadata through a shared _thread_metadata_for_target() helper (the existing _thread_metadata_for_source() now delegates to it, with byte-identical behavior for its 18 callers).
• Preserve chat_type in the /update and /restart marker payloads so post-restart paths can reconstruct DM-topic routing.
• For DM-topic targets, attach the anchorless routing keys (telegram_dm_topic_reply_fallback, direct_messages_topic_id). The Telegram adapter's _is_private_dm_topic_send() short-circuits to False when direct_messages_topic_id is present, so the send routes via the topic id and no longer requires a reply anchor.
• Keep home-channel startup notifications on the same metadata path.
• Tighten regression coverage to assert the full DM-topic metadata, not just thread_id.

Follow-up commit (hardening)

The contributor's _is_telegram_dm_topic_target probed adapter._get_dm_topic_info via instance-level getattr. A MagicMock auto-creates that attribute as a truthy callable, so any test double with a non-dm chat_type + a thread_id would be misclassified as a DM topic lane and get the fallback keys injected. The follow-up resolves the method on type(adapter) and treats only dict-shaped returns as an operator-declared topic — mirroring the existing guard in _rename_telegram_topic_for_session_title. The home-channel test is updated to declare _get_dm_topic_info on a real adapter subclass instead of patching a MagicMock onto the instance.

Why no message_id anchor was needed

The reported root cause suggested storing event.message_id as a reply anchor. That works, but the adapter already supports an anchorless routing path for synthetic sends (introduced in #27937): when direct_messages_topic_id is present, _is_private_dm_topic_send() returns False and _thread_kwargs_for_send() returns {"message_thread_id": None, "direct_messages_topic_id": <tid>}. This fix uses that path, which is the correct mechanism for sends that have no originating message to reply to.

Testing

• Cherry-pick applies cleanly onto current main (+121/-25, matching the original PR).
• tests/gateway/test_update_command.py + tests/gateway/test_restart_notification.py: 53 passed.
• Full sweep across the 13 test files exercising the refactored helper: 489 passed.
• ruff clean, py_compile clean.
• E2E: reproduced the exact failure — wrote a .restart_notify.json marker for a DM topic (thread 777, chat_type dm), ran _send_restart_notification(), fed the resulting metadata into the real TelegramAdapter decision logic. On main _is_private_dm_topic_send → True (→ the error); with this PR → False, routing via direct_messages_topic_id. Confirmed the notification now delivers.
• E2E (hardening): a bare-MagicMock adapter with a non-dm chat_type is no longer misclassified; real adapters returning a dict / None behave correctly.

Closes #34144

Co-authored-by: Dusk1e yusufalweshdemir@gmail.com

[alt-glitch]

Supersedes #34144 — salvage onto current main with additional hardening (MagicMock DM-topic misclassification fix). Related to merged #28488 and #28487.