Summary

Closes #5111. Important framing: #5111 was filed against
v2026.5.12-beta.11, when telegram was the in-process Rust
librefang-channels::telegram adapter — that adapter exited its
polling task on a transient network failure and the bridge stayed
dead until the daemon was restarted, exactly as the issue describes.
The #5241 sidecar migration replaced it with the Python sidecar at
sdk/python/librefang/sidecar/adapters/telegram.py, which already
wraps _poll_once in a while True / except Exception → backoff
loop. The reported symptom is therefore already fixed in main.

This PR is not the bug fix — that was #5241. It is the
observability + cap-alignment + regression coverage that should have
shipped alongside #5241 so a future refactor can't reintroduce the
original failure mode invisibly.

Changes

sdk/python/librefang/sidecar/adapters/telegram.py

1. Backoff cap aligned: hardcoded 120.0 → new
   MAX_BACKOFF_SECS = 60.0 module constant, matching every sibling
   polling sidecar (bluesky, discord, line, mastodon, mattermost,
   nextcloud, ntfy, reddit, rocketchat, twitch). Behavioural change
   — persistent-outage retries now cap at one-minute intervals
   instead of two-minute ones.
2. WARN gets retry counter: each backoff WARN now carries
   retries=<consecutive-failure-count> so degraded duration is
   readable off a single log line.
3. INFO on recovery: first successful poll after ≥1 retry emits
   telegram poll recovered retries=N last_backoff=…. Recovery
   already worked; this makes it visible (closes the issue's
   "restored DNS — bridge does NOT recover" symptom, which was
   actually "recovers silently").
4. TimeoutError isolated: LONGPOLL_SERVER_SECS server-side block
   expiring (normal protocol behaviour) explicitly resets both
   backoff and retries_in_a_row and continues without
   consuming the sleep budget — an idle channel never drifts toward
   MAX.

Deliberately NOT done

The issue suggested "Log WARN on each retry attempt, ERROR only after
N consecutive failures". Skipped because:

• Every sibling polling sidecar reserves log.error for fatal
  startup-config issues (*_required env vars missing,
  token validation failed, webhook bind failed). None escalate
  during steady-state backoff.
• The producer-crash path in librefang.sidecar.runtime already
  emits log.error("producer crashed", …) if an exception ESCAPES
  produce(); the backoff loop is the layer that prevents that
  escape — escalating from inside it would muddy the signal.
• The new WARN-with-retry-counter + INFO-on-recovery already
  provide the "how long degraded / when restored" signals operators
  need.

If a maintainer wants ERROR escalation across the whole sidecar
family for parity, that's a separate change to be applied
consistently to all 11 polling sidecars.

Regression guards (3 new pytest cases)

• test_produce_recovers_after_startup_network_failure — URLError
  on first poll → warn + sleep + retry → success + INFO recovered
• test_produce_backoff_is_capped_at_max — consecutive failures
  produce delays = [1, 2, 4, 8, 16, 32, 60, 60, …], max never
  exceeds MAX_BACKOFF_SECS, the cap is actually reached
• test_produce_treats_longpoll_timeout_as_normal — TimeoutError
  alternating with success → loop re-enters without sleeping, no
  backoff growth

All three monkeypatch tg.asyncio.sleep against a saved real-sleep
closure to avoid the infinite-recursion footgun (tg.asyncio and the
test file's asyncio import point at the same module object).

Verification

pytest sdk/python/tests/test_telegram_adapter.py
# 26 passed (3 new + 23 existing)

Test plan

• Live: stop the network, observe one WARN every backoff
  interval with rising retries=. Restore the network, observe one
  INFO telegram poll recovered retries=N last_backoff=…. Bridge
  continues operating without daemon restart.
• CI integration smoke green.