fix(telegram): recover from post-update polling conflict without entering limbo (closes #23783)

[teknium1]

Salvage of #25630 (@CryptoByz).

Summary

hermes update while the gateway is active leaves Telegram broken in two ways:

Stage 1 — 409 Conflict on startup. Telegram keeps its getUpdates long-poll session open ~30s after the old process exits. The watcher respawns with no delay → 409 from Telegram's API before the server-side session expires.

Stage 2 — Silent limbo after failed retry (worse bug). _handle_polling_conflict would sleep 10s, retry start_polling(). If that retry itself raised, the method silently returned. updater.running=False, no fatal error set, gateway reports 'connected', no messages flow. Only recovery was a manual restart.

Changes

• gateway/platforms/telegram.py: MAX_CONFLICT_RETRIES 3→5, exponential backoff 10 + count*10, self-rescheduling on retry failure (no more silent limbo).
• hermes_cli/main.py: add startup grace delay for the watcher respawn.

Validation

• scripts/run_tests.sh tests/gateway/test_telegram_conflict.py -q → 6/6 passing.

Follow-up commit updates test_polling_conflict_becomes_fatal_after_retries to match the new MAX=5 invariant (was hardcoded against MAX=3).

Also supersedes #23806 (@im-kris) and #27099 (@randiri100) — both fixed subsets of this — closed with credit.

Authorship preserved via cherry-pick. AUTHOR_MAP entry added in follow-up.

[github-actions]

🔎 Lint report: hermes/hermes-6063e704 vs origin/main

ruff

Total: 0 on HEAD, 0 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 0 pre-existing issues carried over.

ty (type checker)

Total: 8881 on HEAD, 8881 on base (➖ 0)

🆕 New issues: none

✅ Fixed issues: none

Unchanged: 4652 pre-existing issues carried over.

Diagnostics are surfaced as warnings — this check never fails the build.