A final reply the platform rejected with anything other than flood control
(a 5xx, a transient parse error, an unclassified failure) sat in the ledger
as `failed` until the next gateway restart, because the runtime sweep only
claimed `send_path_degraded` and flood rows and no timer was armed for it
(#91653). The deadline-driven redelivery worker main already runs for flood
rows now covers every failed row: `retry_not_before` keeps the platform's
wait for flood rows, retries allowlisted reconnect errors at once, backs
any other rejection off by attempts (30 s, 2 min, 10 min) so an outage is
not hammered, and returns None for a whole-chat death (blocked bot, deleted
chat) so a dead target is never resent. `pending_flood_retries` becomes
`pending_retries`; the adapter arms the timer on every rejection.
`release_runtime_claim`'s attempts decrement is untouched: it refunds an
attempt a claim never spent, which the backoff relies on unchanged.
design via #91655 by @dasgltd
Co-authored-by: Daniel Silva <daniel@dasg.ltd>
c961e5bb69