fix(telegram): recover when a polling-conflict retry fails

[randiri100]

Problem

When Telegram returns a 409 Conflict: terminated by other getUpdates request, _handle_polling_conflict stops the updater, waits, and retries start_polling(). If that retry itself fails (e.g. a TimedOut/NetworkError because the host's connectivity is also flaky at that moment), the except block only logs the failure and returns — relying on a comment that says "wait for the next conflict to trigger another retry attempt".

But once start_polling() fails, the long-poll is dead and no error callback can ever fire again. There is no "next conflict". The bot is left permanently wedged with polling stopped, until the gateway process is manually restarted. Outbound sends keep working, which masks the failure — cron-driven messages still go out while the bot silently stops receiving anything.

Observed in production: a 409 conflict at the same time as a brief network blip → one retry → start_polling() raised TimedOut → handler returned → ~2h of dropped inbound messages until a manual restart.

Fix

The network-error handler (_handle_polling_network_error) already guards against this exact dead-end: when its retry's start_polling() fails, it self-schedules the next attempt instead of relying on a callback that can't fire.

This applies the same pattern to the conflict handler. When a conflict retry's start_polling() fails:

• a transient network failure routes into _handle_polling_network_error (exponential-backoff ladder, which can escalate to a retryable-fatal gateway restart);
• anything else re-enters the conflict ladder.

Either way the recovery is self-scheduled as a background task, so the poller is never left wedged with nothing to wake it.

Test

Adds test_conflict_retry_network_failure_schedules_recovery to tests/gateway/test_telegram_conflict.py, asserting a conflict retry that fails with a network error routes into the network reconnect ladder. Full suite (test_telegram_conflict.py + test_telegram_network_reconnect.py) passes — 22 tests.

🤖 Generated with Claude Code

[alt-glitch]

Competes with #25630 (same polling-conflict recovery pattern). Both fix the dead-poller scenario where _handle_polling_conflict's retry start_polling() fails and nothing re-triggers recovery. Also related to #25232.

[teknium1]

Closing in favor of #25630 (broader scope on the same bug — #23783 / silent-limbo after failed polling-conflict retry).

Both PRs apply the same insight: _handle_polling_conflict's except branch silently returns, leaving the bot wedged. Both PRs apply the self-rescheduling pattern from _handle_polling_network_error. #25630 (@CryptoByz) was submitted first and additionally addresses Stage 1 (hermes update / watcher respawn race against Telegram's ~30s server-side session grace).

Thanks for the parallel work.