From post-merge audit of PR #28505 (#25368 salvage, report cron topic fallback).

Bug

gateway/platforms/telegram.py around line 1755 handles "thread not found" errors with a two-step retry:

1. First attempt: await asyncio.sleep(1) then retry with the SAME message_thread_id.
2. Second attempt (after the first inevitably fails): retry without message_thread_id.

Step 1 cannot succeed — if Telegram just rejected the thread, the thread is genuinely gone or stale. Sleeping 1s and re-sending the same request just adds 1s of latency to every thread-not-found error before the actual fix (drop thread_id) runs.

Repro path

Cron delivery to a configured topic that was deleted on the Telegram side:

1. Cron schedules send to telegram:chat_id:stale_thread_id.
2. Telegram rejects: Bad Request: message thread not found.
3. Adapter sleeps 1s, retries with same stale_thread_id → fails again.
4. Adapter retries without thread_id → succeeds.
5. Cron observes thread_fallback metadata, marks delivery degraded.

Total latency: ~1s + 2 HTTP round-trips when 1 HTTP round-trip would suffice.

Fix

Drop the retried_thread_not_found first-retry step. Go straight from "thread not found" to "retry without message_thread_id":

if self._is_thread_not_found_error(send_err) and effective_thread_id is not None:
    logger.warning(
        "[%s] Thread %s not found, retrying without message_thread_id",
        self.name, effective_thread_id,
    )
    used_thread_fallback = True
    effective_thread_id = None
    thread_kwargs = {"message_thread_id": None}
    continue

Scope

Affects every thread-not-found error. Common for cron deliveries to deleted topics and any send to a stale dm_topic_id. Low risk — the second retry path was always going to run anyway, just 1s later.