Приём отвечает 200 до свёртки, свёртку ведёт фоновый воркер

- Очередью служит сама таблица: доставка ждёт свёртки в статусе `pending`,
  канал несёт только бит «есть работа». Переполнять нечего, падение процесса
  очередь не теряет, а подбор `pending` при старте — обычный проход воркера, а
  не отдельный код. Классификация исхода общая с пересборкой журнала.
- Исход разбора начал отражать доставку, а не обстоятельства: отмена и
  занятость базы статус не меняют (иначе конкуренция за базу выводила бы
  доставку из очереди навсегда), паника свёртки больше не валит процесс, а
  учёт доставки идёт через транзакцию с повторами.
- Длинный бюджет ответа выдан маршруту приёма, а не всему серверу:
  `write_timeout` в Go покрывает и чтение тела, и общий подъём снял бы защиту с
  остальных маршрутов.

config.example.toml

@@ -7,7 +7,12 @@
 [server]
 addr          = ":8080"   # адрес прослушивания; ":8080" — все интерфейсы (нужно, чтобы телефон достучался по локальной сети)
 read_timeout  = "5m"      # на всё чтение запроса вместе с телом; Go-duration. Щедро: экспорт истории — десятки мегабайт по мобильной сети
-write_timeout = "30s"     # на отправку ответа; Go-duration
+# ВНИМАНИЕ: write_timeout в Go покрывает НЕ только отправку ответа. Он ставится
+# до вызова обработчика и потому включает чтение тела: значение меньше
+# read_timeout молча обрывает медленную загрузку. Маршрут приёма поэтому держит
+# собственный бюджет (read_timeout + write_timeout), а это значение остаётся
+# защитой от застрявшей записи ответа на остальных маршрутах.
+write_timeout = "30s"     # на отправку ответа прочих маршрутов; Go-duration
 
 [auth]
 # Токены проверяются как `Authorization: Bearer <токен>`.