fix(gateway): recover Telegram polling after conflicts (#40691)

[Tranquil-Flow]

What

Fixes #40691 by hardening Telegram polling conflict recovery so the gateway does not remain alive-but-wedged after a 409 conflict.

Changes:

• restart conflict polling with drop_pending_updates=True to clear stale getUpdates state
• schedule _verify_polling_after_reconnect() after successful conflict retry, matching the network-reconnect path so a wedged updater is detected and recovered
• add focused regression coverage in the existing Telegram reconnect tests for both layers

Why

The issue reports that after conflict recovery the gateway logs "polling resumed" but stops processing both DMs and passive group routing until a full restart. The existing conflict retry could resume from stale pending updates and had no post-reconnect probe, so a dead consumer could sit silently while the process still reported healthy.

Verification

• RED check on upstream/main: revised regression tests failed before the production change:
  • test_conflict_retry_drops_pending_updates_and_preserves_callback
  • test_conflict_retry_schedules_heartbeat_probe_on_success
• GREEN after fix:
  • /Users/evinova-self/.hermes/hermes-agent/venv/bin/python3 -m pytest tests/gateway/test_telegram_network_reconnect.py tests/gateway/test_telegram_conflict.py -v -o "addopts=" --tb=short
  • Result: 23 passed in 0.42s
• Branch verified exactly one commit ahead of upstream/main: 0 1

Competitor analysis

Open PR #40744 changes drop_pending_updates only. It does not add the post-reconnect verification probe, has no focused regression tests, and includes an unrelated tools/lazy_deps.py change. This PR covers both reported recovery layers with focused tests and a smaller final diff.

Auto-published by Moonsong via Path B automated pipeline.

[teknium1]

Automated hermes-sweeper review: this PR's target behavior has been superseded on current main by a stronger Telegram polling recovery path.

Evidence:

• plugins/platforms/telegram/adapter.py:2035 now has the live _handle_polling_conflict() path in the plugin Telegram adapter. It stops/drains/restarts polling, resets the conflict counter on success, and reschedules failed retries instead of leaving the adapter alive-but-wedged.
• plugins/platforms/telegram/adapter.py:1972 and plugins/platforms/telegram/adapter.py:2723 add and wire _disarm_ptb_retry_loop() so PTB's own getUpdates retry loop is stopped synchronously before Hermes schedules conflict recovery. That landed in f03823014b01b7b85a6777040e1bb02a68cf8877.
• plugins/platforms/telegram/adapter.py:1866 adds pending-update wedge detection: if Telegram reports queued updates while Hermes believes polling is running, recovery re-enters the existing reconnect ladder. That landed in d5ba374c038a99db99e3036d938271e70a6930fd.
• The linked issue [BUG] Telegram Gateway freezes after polling conflict recovery — passive routing stops working #40691 was closed by a maintainer as substantially fixed on current main, specifically citing the conflict recovery state machine, heartbeat loop, and pending_update_count wedge detector.

The specific drop_pending_updates=True conflict-retry tweak from this PR was not adopted, but the reported failure mode it was fixing is covered by the newer mainline implementation. Thanks for the focused reproduction and tests; they lined up with the recovery hardening that landed.