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

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

openspec/specs/parsing/spec.md

@@ -252,6 +252,11 @@ Export шлёт под одним именем, чтобы одно имя оз
 Система MUST сохранять правило «сохранили — значит приняли»: исход разбора не
 меняет код ответа на доставку.
 
+Разбор идёт **после** ответа, поэтому исход виден не в ответе и не в момент
+ответа, а асинхронно — в `delivery.parse_status` и в записи лога. Когда именно
+отдаётся ответ и кто сворачивает принятое, определяет capability `ingest`;
+здесь нормируется только то, что от разбора код ответа не зависит.
+
 #### Scenario: Содержимое не разобралось
 
 - **WHEN** тело сохранено в архив, но разбор его содержимого не удался