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

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

docs/database.md

@@ -56,7 +56,14 @@ SQLite (`modernc.org/sqlite`, чистый Go), миграции — goose, фа
 | `derived_layer` | слой, выведенный для этой доставки. Нужен не отчётности, а самому выводу: доставка без плотных метрик наследует последний надёжно выведенный слой той же автоматизации, и без хранения этой памяти первая такая доставка после перезапуска осталась бы без слоя |
 
 Индексы: `delivery_received_at` (порядок журнала), `delivery_sha256` (учёт
-повторов), `delivery_automation_layer` (поиск последнего слоя автоматизации).
+повторов), `delivery_automation_layer` (поиск последнего слоя автоматизации),
+`delivery_pending` (очередь свёртки).
+
+`delivery_pending` **частичный** — только строки со статусом `pending`. Таблица
+и есть очередь фоновой свёртки: воркер выбирает неразобранные доставки в
+порядке журнала чаще, чем раз в минуту. В установившемся режиме в индексе
+ноль-одна строка, тогда как полный индекс по `parse_status` хранил бы всю
+историю ради выборки из одной.
 
 ## `bucket` — часовой объект точек