Closes #98774

What Problem This Solves

Fixes an issue where a Telegram spooled update that keeps failing would retry every ~500ms forever with no backoff and no attempts cap — and because the spool drain claims the lowest update id per conversation lane, the poison row permanently blocked every later message in that chat/topic. Two directly associated spool defects are fixed with it: a transient store read error during restart replay silently deleted the spooled message (the same loss window #98076 closed for media, still open for store reads), and successfully processed rows were deleted instead of tombstoned, so a crash-window Telegram refetch could re-dispatch an already-processed update — including re-executing callback-query side effects.

Why This Change Was Made

Three commits, in dependency order. First, the one-off session-init-conflict backoff (from 13ecca5408c) is generalized: all retryable spooled failures now back off exponentially from the queue's persisted attempts/lastAttemptAt (1s base, 3m cap) and dead-letter to the existing failed tombstones after 8 attempts, unblocking the lane. Second, TelegramPairingStoreReadError in the inbound handler now records a failed-retryable result so spooled replays are requeued instead of deleted; the user-facing "please try again" apology is suppressed for replays (they retry durably) and kept for live updates (acked without retry). Third, the success path uses the ingress queue's complete() tombstones (30d/1000 retention, pruned on the existing enqueue-side prune) so enqueue-time duplicate detection absorbs refetches; a redrain-ordering fix ensures lane guards clear before a requested immediate redrain.

User Impact

One malformed or persistently failing message can no longer silently freeze an entire Telegram chat or topic — it retries with backoff, then dead-letters with a warning log operators can find. Messages that hit transient store errors during a gateway restart are retried instead of lost, without apology spam. Buttons and commands no longer risk double-execution after a crash-window refetch.

Evidence

• Regression tests added: dead-letter after max attempts unblocks the lane and later updates in the same lane process (polling-session.test.ts, 72 pass); transient pairing-store error on spooled replay requeues instead of deleting, with no repeated apologies (bot.create-telegram-bot.test.ts, 113 pass); completed-then-refetched update is detected as duplicate and not re-dispatched, at both queue and drain level (telegram-ingress-spool.test.ts, 14 pass).
• Validation: pnpm tsgo:extensions pass; node scripts/run-oxlint.mjs on touched files pass; repo autoreview (branch mode vs origin/main) clean.
• Combined-merge validation with the sibling PR (codex/fix-telegram-cache-transport): conflict-free octopus merge, pnpm tsgo:extensions pass, 403/403 tests across all six touched test files.
• Constants chosen: max attempts 8, retry base 1s, retry cap 3m, completed tombstone TTL 30d / max 1000 (matching the existing failed tombstone bounds).