fix(telegram): drop pending updates on conflict recovery (#40691)

[kyssta-exe]

Fixes #40691. After a Telegram polling conflict (HTTP 409), the gateway restarted polling with drop_pending_updates=False, which resumed from a stale update offset and caused the long-poll connection to stall silently. Changing to drop_pending_updates=True clears the stale queue on recovery so fresh updates flow normally.

[teknium1]

Automated hermes-sweeper review: this PR's reported Telegram polling-conflict freeze is already fixed on current main by later recovery hardening, so this branch is now redundant.

Evidence:

• Current main moved the Telegram adapter to plugins/platforms/telegram/adapter.py; _handle_polling_conflict() now reschedules failed recovery attempts instead of leaving the gateway alive but silently not receiving messages (plugins/platforms/telegram/adapter.py:2035, plugins/platforms/telegram/adapter.py:2050).
• Current main also detects the wedged-consumer case directly via get_webhook_info().pending_update_count and routes it back into the recovery ladder after consecutive stuck probes (plugins/platforms/telegram/adapter.py:1866; commit d5ba374c038a99db99e3036d938271e70a6930fd).
• The regression coverage for that recovery path lives in tests/gateway/test_telegram_pending_update_probe.py:60.
• The linked issue [BUG] Telegram Gateway freezes after polling conflict recovery — passive routing stops working #40691 has since been closed by a maintainer as substantially fixed on current main, specifically citing the conflict-recovery hardening and d5ba374c0 pending-update wedge detection.
• The one-line drop_pending_updates=True change from this PR was not the path main took; current main deliberately preserves queued updates on reconnect/conflict recovery while using health checks to recover from a stuck poller (plugins/platforms/telegram/adapter.py:2458).

Thanks for the useful diagnosis and PR. The underlying bug class has been addressed on main, so this branch can be closed as implemented there.