docs(ingestion): упрощены объяснения источников и приема данных

Зачем: помочь начинающему инженеру проследить событие и версию заказа
от генератора до хранилища, включая ошибки и повторные поступления.

Что: обновлены вводная генератора, справочники приема и модели заказа,
разделы хранилища и комментарии SQL и дага. Сохранены технические условия;
исполняемый код, схемы и поведение стенда не изменены.

Проверка: make lint, git diff --check, 142 локальные ссылки и справка CLI.
SQL без комментариев и Python AST без строк документации совпали
с исходными. Генерация данных и сброс состояния не выполнялись.

Refs #250

dags/orders_ingest.py

@@ -1,18 +1,13 @@
-"""Приём заказов: пакетный забор слепка из Kafka в хранилище.
+"""Пакетный прием заказов: Kafka → STG → ODS.
 
-Путь Kafka → STG → ODS у заказов один и живёт одним дагом: сначала забор
-порции в `stg`, затем разбор того же среза в типизированный ODS и в таблицу
-брака. Расписания у дага нет: его дёргает тот, кто положил слепок в топик, —
-шаговый даг модельного времени после проигрыша дня, — и ждёт конца.
+Шаговый даг модельного времени отправляет слепок, запускает orders_ingest
+и ждет его завершения. Собственного расписания у orders_ingest нет.
+Сначала pull_batch сохраняет порцию сообщений в STG, затем parse_batch
+разбирает тот же срез по _load_id в заказы и ошибки.
 
-Контраст с приёмом событий и есть урок. События тянет матвью, навсегда
-подписанная на чтеца: приём идёт сам, пока идёт поток. Слепок заказов
-приезжает раз в модельный день целой выгрузкой, у которой есть начало и конец,
-и забирает её запрос по команде. Push против pull — два режима на одном стенде,
-каждый там, где ему место по природе источника.
-
-Решения и доводы целиком — ADR 0008 (забор) и ADR 0010 (версии в ODS); форма
-перехода — docs/architecture/orders/ingestion.md.
+События принимаются непрерывно через материализованные представления.
+Заказы читаются одним запросом; полнота слепка этим не гарантируется.
+Правила и ограничения — docs/architecture/orders/ingestion.md.
 """
 
 from __future__ import annotations
@@ -24,8 +19,7 @@ from airflow.sdk import dag
 
 START_DATE = datetime.datetime(2026, 1, 1, tzinfo=datetime.UTC)
 
-# Запросы лежат файлами в sql/ репозитория, разложенные по слоям хранилища;
-# сюда их монтирует compose — всем службам Airflow сразу.
+# Compose монтирует sql/ по этому пути во все службы Airflow.
 SQL_ROOT = "/opt/airflow/sql"
 
 
@@ -34,15 +28,14 @@ SQL_ROOT = "/opt/airflow/sql"
     schedule=None,
     start_date=START_DATE,
     is_paused_upon_creation=False,
-    # Чтец у топика один, и группа потребителей у него одна. Два прогона разом
-    # дрались бы за неё, а слепок разъехался бы по двум _load_id; второй
-    # прогон подождёт своей очереди.
+    # Один запуск за раз: параллельные чтения разделили бы порцию
+    # между разными _load_id.
     max_active_runs=1,
     template_searchpath=SQL_ROOT,
     tags=["заказы"],
 )
 def orders_ingest():
-    """Забрать приехавший слепок заказов и разложить его по слоям."""
+    """Сохранить порцию заказов и разобрать ее в ODS."""
     pull_batch = SQLExecuteQueryOperator(
         task_id="pull_batch",
         conn_id="clickhouse_default",
@@ -59,8 +52,8 @@ def orders_ingest():
         do_xcom_push=False,
     )
 
-    # ClickHouse не даёт транзакции между двумя вставками parse_batch. Один
-    # task_id сохраняет их порядок и одну точку повтора для неизменного load_id.
+    # Две вставки parse_batch не образуют транзакцию. Повтор задачи
+    # выполняет обе над тем же срезом STG по _load_id.
     pull_batch >> parse_batch