docs(ods): описана семантика snapshot_date после схлопывания версий

- Зачем:
  - проверка #137 показала: у заказа, не менявшегося несколько дней, версию
    выбирает только updated_at, и какая из одинаковых строк переживёт
    схлопывание — не обещано; snapshot_date выжившей строки означал не то,
    что обещала документация (у 86 заказов стартового мира выжил серединный
    день наблюдения).
- Что:
  - в docs/architecture/orders/ingestion.md записано: snapshot_date, _load_id
    и _load_ts выжившей строки — координаты одного из наблюдений версии, не
    обязательно последнего; допущение «уточнение поднимает updated_at»
    названо допущением с границей применимости.
  - та же оговорка — в комментарии DDL ods.order_rep.
- Проверка:
  - замеры на живом стенде: во всех 3034 парах строк с равным updated_at
    деловые поля совпали побайтово; монотонность updated_at по слепкам —
    без нарушений; ods.order_v сошёлся с эталоном argMax из сырья построчно.

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

sql/ddl/20-ods-tables.sql

@@ -163,7 +163,10 @@ ENGINE = Distributed('clickstream_cluster', 'ods', 'event_errors_rep', cityHash6
 -- updated_at — какая бизнес-версия новее; snapshot_date — в слепке какого
 -- модельного дня источник показал строку; _load_id — какой запуск Airflow её
 -- принял; _load_ts — когда она приехала в хранилище. Ключом сущности не
--- становится ни одна из трёх последних: они про наблюдение и загрузку.
+-- становится ни одна из трёх последних: они про наблюдение и загрузку. Версию
+-- выбирает только updated_at, поэтому у выжившей после схлопывания строки
+-- snapshot_date — один из дней, когда источник показывал эту версию, не
+-- обязательно последний (docs/architecture/orders/ingestion.md).
 --
 -- PARTITION BY toDate(created_at) — по дню создания строки в источнике. Он
 -- неизменен у всех версий заказа, поэтому версии лежат в одной партиции и