refactor(ods): упрощены имена таблиц заказов

- Зачем:
  - ODS должен показывать сущность заказа, а не способ её доставки слепком.
- Что:
  - физические таблицы и представление переведены на имена `order_*`.
  - SQL загрузки, DAG и документация приведены к тому же словарю.
- Проверка:
  - `make config-test`, `make lint`.
  - `make clean && make up`, `make smoke`, `make check-clickhouse`, `make check-services`.

docs/specs/2026-07-30-stand-v2-realism.md

@@ -219,7 +219,7 @@ Ecommerce (заполнены только у торговых событий):
   Обоснование и проверка разбора — в
   [исследовании формата](../research/2026-08-16-order-snapshot-wire-format.md).
 
-- `ods.order_snapshot` принимает версии заказа в
+- `ods.order` принимает версии заказа в
   `ReplacingMergeTree(updated_at)`: `ORDER BY order_id`, партиция по дню
   неизменного `created_at`, шардирование по `cityHash64(order_id)`.
   `snapshot_date` остаётся датой наблюдения источника, но не задаёт публикацию
@@ -410,7 +410,7 @@ README.
 | STG | `stg.hits_raw_kafka`, `stg.hits_raw` + MV | сырые строки событий, Kafka Engine на обеих нодах |
 | STG | `stg.orders_raw_kafka`, `stg.orders_raw`, без MV | сырые строки слепка; чтец на ноде 1, забирает пакетный шаг |
 | ODS | `ods.event` (+`_errors`), `ods.event_v` | типизированные версии событий, брак и точное актуальное состояние |
-| ODS | `ods.order_snapshot` (+`_errors`), `ods.order_v` | типизированные версии заказов, брак и точное текущее состояние |
+| ODS | `ods.order` (+`_errors`), `ods.order_v` | типизированные версии заказов, брак и точное текущее состояние |
 | DDS | `dds.session` | сборка сессий из событий (наследник `dds.click`) |
 | DDS | `dds.event_v` | представление над `ods.event`: snake_case-имена, расшифровка кодов `DeviceCategory`; витрины DM читают его, а не ODS напрямую |
 | DDS | модель заказов | зерно, связи и материализация проектируются на этапе DDS |
@@ -428,7 +428,7 @@ README.
 матвью к нему не привязана, и сырьё забирает шаг, которым управляет Airflow —
 одно прямое чтение вставляет порцию в `stg.orders_raw` с `_load_id` запуска.
 Один следующий `task_id` двумя последовательными запросами пишет годные строки
-и ошибки из того же среза. `ods.order_snapshot` хранит версии по `updated_at`,
+и ошибки из того же среза. `ods.order` хранит версии по `updated_at`,
 а не публикует партицию `snapshot_date`. Слой сырья остаётся точкой повтора и
 разбора одной принятой порции.
 
@@ -436,7 +436,7 @@ README.
 из опорных точек раздела 12 переформулировано под них.
 
 Состав служебных колонок задаёт дока хранилища. Спеке важны два следствия:
-`ods.event` и `ods.order_snapshot` получают метку загрузки `_load_ts`, но у
+`ods.event` и `ods.order` получают метку загрузки `_load_ts`, но у
 заказа бизнес-версию задаёт `updated_at`; `_load_id` проходит через STG и обе
 цели ODS. Таблицы
 `stg.*_raw` хранят метаданные доставки Kafka вместе с именем читавшей ноды —