docs(orders): документация перестроена вокруг текущей модели

- Зачем:
  - описание вело нового читателя через историю исправления вместо действующего
    контракта слоёв.
- Что:
  - прямо описаны версия заказа, границы пакетного приёма и расчёт окна DDS.
  - ответственность ODS, DDS и конвейера разделена без ссылок на прежние
    ошибки как на основной довод.
  - исторический вывод исследования помечен до устаревшего абзаца, а ссылки
    ведут к отдельным решениям и контрактам.
- Проверка:
  - make lint.
  - make config-test.

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

@@ -222,10 +222,11 @@ Ecommerce (заполнены только у торговых событий):
 - `ods.order` принимает версии заказа в
   `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 одна строка хранит
+  слепка служит колонкой версии: выживает строка с максимальной
+  `snapshot_date` ([ADR 0014](../adr/0014-order-version-snapshot-date.md)).
+  Дата не доказывает полноту принятой порции, поэтому ODS не заменяет партицию
+  слепка целиком. Физическое чтение может видеть несколько версий;
+  `ods.order_v` возвращает точное текущее состояние. В DDS одна строка хранит
   один заказ с позициями в типизированных массивах; физическая модель и
   пакетное наполнение описаны в [доке заказа](../architecture/dds/order.md).
 
@@ -453,13 +454,9 @@ README.
 матвью к нему не привязана, и сырьё забирает шаг, которым управляет Airflow —
 одно прямое чтение вставляет порцию в `stg.orders_raw` с `_load_id` запуска.
 Один следующий `task_id` двумя последовательными запросами пишет годные строки
-и ошибки из того же среза. `ods.order` хранит версии по дате слепка
-([ADR 0014](../adr/0014-order-version-snapshot-date.md)), а не публикует
-партицию `snapshot_date`. Слой сырья остаётся точкой повтора и
-разбора одной принятой порции.
-
-Стенд получает от этого два режима приёма рядом, поток и слепок, и сравнение
-из опорных точек раздела 12 переформулировано под них.
+и ошибки из того же среза. `ods.order` выбирает текущую версию по максимальной
+`snapshot_date` ([ADR 0014](../adr/0014-order-version-snapshot-date.md)). Слой
+сырья остаётся точкой повтора и разбора одной принятой порции.
 
 Состав служебных колонок задаёт дока хранилища. Спеке важны два следствия:
 `ods.event` и `ods.order` получают метку загрузки `_load_ts`, но версию