feat(orders): добавить приём слепков в STG

Зачем:
- связать проигрывание модельных дней с пакетным приёмом заказов
- показать на одном стенде различие потокового push и пакетного pull

Что:
- добавлен топик, Kafka-чтец и реплицированное сырьё заказов
- добавлен даг orders_ingest с одним прямым чтением и идентификатором загрузки
- работники мира отправляют слепок, ждут приём и только затем двигают позицию
- решения, границы отказа и проверки отражены в ADR и архитектурных документах

Проверка:
- make lint
- make config-test
- make smoke
- make check-clickhouse
- make check-services

docs/architecture/orders/ingestion.md

@@ -34,9 +34,10 @@
 ## Поток данных
 
 После завершения генератора Airflow один раз читает байтовый Kafka-чтец и
-записывает полученную порцию в `stg.orders_raw`. Все строки получают `_load_id`,
-равный `run_id` Airflow. `_load_ts` вычисляется при этой записи и дальше
-переносится без пересчёта.
+записывает полученную порцию в `stg.orders_raw`. Даг зовётся `orders_ingest`, а
+дёргает его тот, кто положил слепок в топик, — работник пульта мира, — и ждёт
+конца прогона. Все строки получают `_load_id`, равный `run_id` Airflow.
+`_load_ts` вычисляется при этой записи и дальше переносится без пересчёта.
 
 Один следующий `task_id` отвечает за весь переход STG → ODS. Внутри него два
 последовательных `INSERT SELECT` читают неизменный срез по `_load_id`: первый
@@ -119,6 +120,13 @@ JSON-объектом с точным набором ключей: `order_id`, `
 из следующих запусков. После отказа от замены партиции это задержка, а не потеря
 или публикация неполного дня.
 
+Отказ — случай другой, и «хвост дождётся» на него не распространяется. Офсеты
+порции коммитятся в момент чтения, поэтому упавшая вставка уносит прочитанное с
+собой: повторное чтение вернёт ноль, а часть строк может уже лежать на шарде.
+Позиция мира при этом не двигается, и тот же день уедет заново — в сырье он
+окажется частичным дублем, а старый хвост, ушедший той же порцией, не вернётся
+([ADR 0008](../../adr/0008-order-ingestion.md), «Следствия»).
+
 ## Отклонённые варианты
 
 - Партиционная идемпотентность — `REPLACE PARTITION snapshot_date` или
@@ -137,9 +145,6 @@ JSON-объектом с точным набором ключей: `order_id`, `
 
 ## Риски и проверка
 
-- На стандартном мире сверить число отправленных заказов с числом строк,
-  принятых одним прямым чтением. Это разовая приёмка допущения, не постоянный
-  сторож.
 - На малой управляемой порции дать по одной строке каждого класса брака и две
   годные версии одного `order_id`. Две цели должны сохранить все непустые
   сообщения, а `ods.order_v` — вернуть новую версию независимо от фонового
@@ -151,6 +156,11 @@ JSON-объектом с точным набором ключей: `order_id`, `
 
 ## Что проверено
 
+Забор из Kafka в STG снят на живом стенде 18 августа 2026 года при исполнении
+#93: одно прямое чтение приносит весь слепок дня, метаданные доставки доступны,
+офсеты коммитятся, а сбой забора не двигает позицию мира. Числа — [ADR
+0008](../../adr/0008-order-ingestion.md), раздел «Что проверено».
+
 MCP Context7 в сессии проектирования был недоступен. На локальном ClickHouse
 `26.3.17.56` проверено, что прямой `SELECT` Kafka Engine завершается после
 одной порции, а `FINAL` через `Distributed` исполняется на таблицах шардов.