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

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

Taskfile.yml

@@ -41,6 +41,15 @@ tasks:
       # платить за проверку, которая возможна только на этой машине.
       - go test ./internal/replay -run TestReplay -healthlog.archive={{.ARCHIVE | default (printf "%s/data/raw" .ROOT_DIR)}} -v -count=1
 
+  verify:busy:
+    desc: 'Свёртка под удерживаемой блокировкой базы: занятость обязана оставить доставку в очереди (около 25 секунд)'
+    cmds:
+      # Не входит в `task test` и `task gate` намеренно: busy_timeout — пять
+      # секунд, повторов транзакции пять, и гейт гоняет тесты трижды. Проверяет
+      # при этом центральное решение задачи «разнести ответ и свёртку»:
+      # занятость базы — обстоятельство, а не свойство доставки.
+      - go test ./internal/fold -run TestBusy -healthlog.busy -v -count=1
+
   lint:
     desc: Запуск golangci-lint
     cmds: