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

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

docs/research/2026-08-16-order-snapshot-wire-format.md

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