fix(gateway): wait for Telegram polling readiness before restart notification

[webtecnica]

Description

Fixes #69370 — Telegram post-restart notification lost on v0.19.0 (Quicksilver).

Root Cause

The v0.19.0 faster cold-start reaches _send_restart_notification() before Telegram's polling path completes its first successful getUpdates request. At that point _send_path_degraded is still True, so adapter.send() returns SendResult(success=False, error="send_path_degraded") and the notification is lost. Normal messaging works moments later once polling makes progress.

Fix

Introduces _wait_adapter_send_ready() on the gateway runner, which uses duck-typing to detect platform adapters exposing a _polling_progress_event (Telegram adapter) and awaits it with a 15-second bounded timeout before sending lifecycle notifications.

The wait is applied in two places:

1. _send_restart_notification() — the chat-originated /restart reply
2. _send_home_channel_startup_notifications() — the planned-restart home-channel broadcast

Design Notes

• Uses duck-typing rather than isinstance checks, keeping the gateway runner platform-agnostic. Other adapters (Discord, WhatsApp, etc.) have no _polling_progress_event and are no-ops.
• The 15-second timeout prevents the readiness wait from causing a stall on a genuinely unhealthy adapter — it degrades to a debug log and the send proceeds anyway.
• Complements the existing 1-second settle in start() (line 8057) rather than replacing it.
• Tests pass without changes because _wait_adapter_send_ready is a no-op when no _polling_progress_event is set, and existing Telegram adapter tests already cover the _polling_progress_event lifecycle (tests/gateway/test_telegram_polling_progress.py).

Testing

Validated by the reporter's local mitigation (commit 1f3aa26b53) which used the same mechanism. This upstream fix mirrors that approach with a bounded timeout and broader coverage.

Co-authored-by: Marcos (webtecnica) marcos@webtecnica.com.br

[teknium1]

This is an automated hermes-sweeper review. Thanks for identifying the Telegram cold-start race and proposing a bounded readiness synchronization.

• Current main already implements the requested guarantee in 83e30e371fd5764ae1f9d9444e4a554dda6a9cb3 (fix(telegram): require initial polling readiness): plugins/platforms/telegram/adapter.py:2419-2459 requires successful current-generation getUpdates progress before cold connect returns success.
• gateway/run.py:10630-10649 only publishes a connected adapter after that successful connection; restart lifecycle delivery follows later at gateway/run.py:10923-10939.
• tests/gateway/test_telegram_start_polling_timeout.py:97-124 verifies the strict initial-connect path leaves _send_path_degraded false.
• The linked issue [Bug]: Telegram post-restart notification is lost on v0.19.0 when send path is degraded during cold start #69370 has already been closed as implemented on main; its discussion notes that fix(gateway): retry restart completion delivery #70859 concerns separate retry/marker durability behavior.

Closing as implemented on main.