feat(ods): версией заказа стала дата слепка, окно DDS — из данных

- Зачем:
  - ярлык snapshot_date выжившей строки доставался жребием, а объём
    пересборки DDS держался на константе окна с двумя несверяемыми копиями
    (ADR 0014, развилка #163).
- Что:
  - ods.order_rep переведена на ReplacingMergeTree(snapshot_date): выживает
    строка позднейшего слепка, ярлык стал правдивым.
  - order_scope.sql выводит окно из дней последнего слепка; ORDER_WINDOW_DAYS
    и параметр window_days сняты со стенда, мёртвая защита краем источника
    убрана.
  - документы и комментарии SQL приведены к ADR 0014: роль ODS, условие
    «одна дата — один слепок», объём прогона и слепые пятна конвейера.
- Проверка:
  - make lint; make rebuild-storage, затем make smoke, make check-clickhouse,
    make check-services — зелёные.
  - после двух слепков snapshot_date всех 1917 строк ods.order_v равен
    последнему слепку заказа, расхождений ноль; деловые поля построчно
    совпали с эталоном argMax по updated_at из сырья.
  - dds_transform без K: первый прогон 06-01…06-07, после нового дня мира
    06-02…06-08, повтор прогона содержимого не изменил.

Closes #165

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

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

@@ -220,11 +220,12 @@ Ecommerce (заполнены только у торговых событий):
   [исследовании формата](../research/2026-08-16-order-snapshot-wire-format.md).
 
 - `ods.order` принимает версии заказа в
-  `ReplacingMergeTree(updated_at)`: `ORDER BY order_id`, партиция по дню
-  неизменного `created_at`, шардирование по `cityHash64(order_id)`.
-  `snapshot_date` остаётся датой наблюдения источника, но не задаёт публикацию
-  или идемпотентность. Физическое чтение может видеть несколько версий;
-  `ods.order_v` возвращает точное текущее состояние. В DDS одна строка хранит
+  `ReplacingMergeTree(snapshot_date)`: `ORDER BY order_id`, партиция по дню
+  неизменного `created_at`, шардирование по `cityHash64(order_id)`. Дата
+  слепка служит колонкой версии — выживает строка позднейшего слепка
+  ([ADR 0014](../adr/0014-order-version-snapshot-date.md)), — но публикацию
+  и идемпотентность по-прежнему не задаёт. Физическое чтение может видеть
+  несколько версий; `ods.order_v` возвращает точное текущее состояние. В DDS одна строка хранит
   один заказ с позициями в типизированных массивах; физическая модель и
   пакетное наполнение описаны в [доке заказа](../architecture/dds/order.md).
 
@@ -452,17 +453,17 @@ README.
 матвью к нему не привязана, и сырьё забирает шаг, которым управляет Airflow —
 одно прямое чтение вставляет порцию в `stg.orders_raw` с `_load_id` запуска.
 Один следующий `task_id` двумя последовательными запросами пишет годные строки
-и ошибки из того же среза. `ods.order` хранит версии по `updated_at`,
-а не публикует партицию `snapshot_date`. Слой сырья остаётся точкой повтора и
+и ошибки из того же среза. `ods.order` хранит версии по дате слепка
+([ADR 0014](../adr/0014-order-version-snapshot-date.md)), а не публикует
+партицию `snapshot_date`. Слой сырья остаётся точкой повтора и
 разбора одной принятой порции.
 
 Стенд получает от этого два режима приёма рядом, поток и слепок, и сравнение
 из опорных точек раздела 12 переформулировано под них.
 
 Состав служебных колонок задаёт дока хранилища. Спеке важны два следствия:
-`ods.event` и `ods.order` получают метку загрузки `_load_ts`, но у
-заказа бизнес-версию задаёт `updated_at`; `_load_id` проходит через STG и обе
-цели ODS. Таблицы
+`ods.event` и `ods.order` получают метку загрузки `_load_ts`, но версию
+заказа задаёт дата слепка; `_load_id` проходит через STG и обе цели ODS. Таблицы
 `stg.*_raw` хранят метаданные доставки Kafka вместе с именем читавшей ноды —
 без них урок «какая нода читала топик» ненаблюдаем.
 Модельного дня в STG нет: `EventDate` — свойство содержимого, а содержимое