chore(main): объединены локальные и удалённые изменения

- Зачем:
  - локальные уточнения документации нужно опубликовать без потери слитых изменений #96 и #109.
- Что:
  - актуальный `origin/main` объединён с двумя локальными коммитами документации.
  - сохранены уточнения применения настроек ClickHouse и границ проектирования заказов.
- Проверка:
  - `make config-test`.
  - `make lint`.

docs/architecture/orders/README.md

@@ -37,7 +37,7 @@
   `person_id` заказ показывает как `user_id`, кликстрим остаётся анонимным —
   [мост к склейке](identity.md).
 - **Приём — пакетный забор**: одно прямое чтение Kafka в STG, два
-  `INSERT SELECT` в типизированный ODS и таблицу ошибок; `ods.order_snapshot`
+  `INSERT SELECT` в типизированный ODS и таблицу ошибок; `ods.order`
   принимает версии заказа на `ReplacingMergeTree(updated_at)` —
   [приём из Kafka в ODS](ingestion.md).
 - **Стартовый мир отправляет семь слепков** (дни 0…6): у последнего прожитого

docs/architecture/orders/fate.md

@@ -61,7 +61,7 @@
 
 **Что из двух дорог видно.** В `dds.order` дороги неразличимы — там последняя
 версия; различает их история версий: сырьё STG и физические версии
-`ods.order_snapshot` до фоновых слияний, а в витринах — выручка дня, которая
+`ods.order` до фоновых слияний, а в витринах — выручка дня, которая
 сначала выросла, потом убыла. Полное различение не обещано: слепок — состояние
 на границе суток, и оплата с отменой в один день в сырье неразличимы; то же у
 сильно опоздавших, приехавших уже терминальными. Точную форму этого урока

docs/architecture/orders/ingestion.md

@@ -43,12 +43,12 @@
 
 Один следующий `task_id` отвечает за весь переход STG → ODS. Внутри него два
 последовательных `INSERT SELECT` читают неизменный срез по `_load_id`: первый
-пишет годные строки в `ods.order_snapshot`, второй — брак в
-`ods.order_snapshot_errors`. Транзакции между запросами нет. При частичном сбое
-Airflow повторяет весь `task_id`; одинаковые исходные строки и служебные метки
-не вычисляются заново. Запросы лежат рядом с целями:
-[`order_snapshot_load.sql`](../../../sql/ods/order_snapshot_load.sql) и
-[`order_snapshot_errors_load.sql`](../../../sql/ods/order_snapshot_errors_load.sql).
+пишет годные строки в `ods.order`, второй — брак в `ods.order_errors`.
+Транзакции между запросами нет. При частичном сбое Airflow повторяет весь
+`task_id`; одинаковые исходные строки и служебные метки не вычисляются заново.
+Запросы лежат рядом с целями:
+[`order_load.sql`](../../../sql/ods/order_load.sql) и
+[`order_errors_load.sql`](../../../sql/ods/order_errors_load.sql).
 
 Условия запросов взаимодополняющие: один общий предикат определяет брак, а
 годная ветвь использует его буквальное отрицание. Все функции предиката
@@ -90,9 +90,9 @@ JSON-объектом с точным набором ключей: `order_id`, `
 
 ## Роль ODS
 
-`ods.order_snapshot_rep` хранит физически принятые версии в
+`ods.order_rep` хранит физически принятые версии в
 `ReplacingMergeTree(updated_at)`. Ключ сортировки — `order_id`, партиция — день
-неизменного `created_at`. `ods.order_snapshot_dist` шардирует по
+неизменного `created_at`. `ods.order_dist` шардирует по
 `cityHash64(order_id)`: только так все версии заказа попадают на один шард и
 `FINAL` даёт корректный результат через распределённую таблицу.
 
@@ -174,7 +174,7 @@ JSON-объектом с точным набором ключей: `order_id`, `
 После исправления
 [#102](https://git.dementev.space/ddmitry/clickstream-data-platform/issues/102)
 честный прогон дня снят на живом стенде 20 августа 2026 года: все 1694 строки
-слепка дня 7 приняты, `ods.order_snapshot_errors` осталась пустой. У заказа
+слепка дня 7 приняты, `ods.order_errors` осталась пустой. У заказа
 `20260608-0007`, который прежде приходил с отрицательным итогом, теперь
 `5490.00 − 823.50 + 299.00 = 4965.50`.
 

docs/architecture/orders/inventory.md

@@ -25,6 +25,6 @@
   пользователей и число двухкуковых пар растут, пока мир едет, — опоры из них
   не выходит; генератор сторожит хеш, транспорт — счёт событий.
 - **Опись описывает мир, а не доставку.** Работа генератора кончается на
-  Kafka: дошли ли байты до `ods.order_snapshot` — вопрос стенда и его
+  Kafka: дошли ли байты до `ods.order` — вопрос стенда и его
   проверок. Поэтому счёта строк у слепка в описи нет; понадобится проверка
   приёма заказов — число заведётся вместе с ней.