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/research/2026-08-16-order-snapshot-wire-format.md

@@ -135,6 +135,12 @@ parseDateTime64InJodaSyntaxOrNull(
 монотонные миллисекундные `updated_at` на один заказ; отдельный счётчик версий
 без такого сценария был бы лишним.
 
+> Вывод о колонке версии пересмотрен: версию `ods.order` задаёт `snapshot_date`
+> ([ADR 0014](../adr/0014-order-version-snapshot-date.md)). Там же разобрано,
+> почему обещанию документации про ничью — «побеждает вставленная позже» —
+> верить нельзя: замер на стенде его опроверг. Абзац выше оставлен как был,
+> документ историчен.
+
 ## Дата слепка и константы мира
 
 Периодический слепок имеет зерно заранее заданного периода — например, дня, —