fix(telegram): clear stale polling sessions on conflict retry

[andyst-dev]

Summary

• restart Telegram polling conflict recovery with drop_pending_updates=True
• keep normal reconnects preserving pending updates unchanged
• add regression coverage that conflict recovery terminates stale getUpdates sessions

Fixes #75017

Tests

• scripts/run_tests.sh tests/gateway/test_telegram_conflict.py -q
• python3 -m py_compile plugins/platforms/telegram/adapter.py tests/gateway/test_telegram_conflict.py
• git diff --check

[teknium1]

Thanks for the focused regression attempt. The conflict-recovery call is still present on current main, but this change is unsafe as written.

Problems

• plugins/platforms/telegram/adapter.py:3060 changes recovery to drop_pending_updates=True. PTB 22.6 documents that flag as cleaning pending updates, and its bootstrap forwards it to delete_webhook. Hermes explicitly preserves that queue for reconnects because dropping it silently loses messages (plugins/platforms/telegram/adapter.py:3584-3590; tests/gateway/test_platform_reconnect.py:165-169).
• The new assertion only verifies that the mocked start_polling receives the flag (tests/gateway/test_telegram_conflict.py:88,134); it does not establish that the flag terminates a competing getUpdates session.

Suggested changes

• Retain queue preservation and identify a recovery mechanism that can be demonstrated to clear the conflict without deleting queued updates.
• Cover that mechanism with an integration-level test of the PTB bootstrap/API behavior.

Automated hermes-sweeper review.

[teknium1]

PTB 22.6 defines this flag as dropping pending Telegram updates and forwards it to delete_webhook; it does not establish stale-session termination. This conflicts with the adapter's explicit reconnect contract at adapter.py:3584-3590, which preserves queued messages to avoid silent loss. Please keep preservation unless a supported recovery operation can prove both session cleanup and no message loss.

[andyst-dev]

Withdrawing this cut after review: using drop_pending_updates=True in conflict recovery can also delete queued Telegram updates, so it is not safe enough for the reconnect/message-delivery contract. I'll look for a queue-preserving recovery path instead of keeping this unsafe variant open.