docs(orders): уточнён формат слепка и временные поля

- Зачем:
  - аудит источника нельзя смешивать с бизнес-временем и `_load_ts` ClickHouse.
- Что:
  - зафиксированы JSON-контракт слепка, порядок ключей и намеренное различие `Array(Float64)` и `Decimal`.
  - разведены бизнес-время, аудит источника и загрузка; уточнены слой ODS, `snapshot_date` и технический ключ партиции.
  - добавлены термины словаря и исследование точного миллисекундного формата с проверками ClickHouse.
- Проверка:
  - выполнен `git diff --cached --check`.

docs/architecture/storage.md

@@ -116,8 +116,9 @@ keeper, Kafka, каркас сервисов. Этап 2 идёт: в `sql/ddl/`
 колонка молча отвечала бы на другой вопрос.
 
 Само сообщение лежит в колонке `raw` тем, чем пришло: чтец читает байты и ничего
-не проверяет, поэтому там оказываются и целые события, и мусор. Разбирается всё
-это ниже, в матвью ODS — см. [ADR 0005](../adr/0005-event-ingestion.md).
+не проверяет, поэтому там оказываются и целые сообщения, и мусор. События ниже
+разбирают матвью ODS ([ADR 0005](../adr/0005-event-ingestion.md)), заказы —
+пакетный шаг ([ADR 0008](../adr/0008-order-ingestion.md)).
 
 Движок таблицы сырья — обычный `ReplicatedMergeTree`, `ORDER BY (kafka_partition,
 kafka_offset)`: разбор полётов идёт от «какое сообщение», другого ключа у сырья и
@@ -125,15 +126,23 @@ kafka_offset)`: разбор полётов идёт от «какое сооб
 которого он заведён: повтор доставки в сырье обязан быть виден.
 
 Метка времени загрузки зовётся `_load_ts`, тип `DateTime64(3, 'UTC')`. Ставится
-она один раз, в матвью приёма, и дальше переносится из STG в ODS как есть:
-колонка отвечает на вопрос «когда строка приехала в хранилище», а не «когда её
-разобрали». В ODS она же служит колонкой версии `ReplacingMergeTree`, и работа у
-этой версии ровно одна — схлопнуть повтор доставки. Содержимое у повтора то же
-самое, отличается только метка, поэтому какая из двух строк переживёт мерж,
-безразлично. Пакетной переобработки у ODS нет: слой наполняет матвью, а не
-задание Airflow, и работа с партициями начинается выше. Переделать разобранное
-руками можно — вставкой из сырья с фильтром по `_load_ts`, в пределах
-трёхсуточного окна; ничья по версии разрешается в пользу вставленного позже.
+она один раз при записи в STG: для событий — матвью приёма, для дневного слепка
+заказов — пакетным шагом. Дальше метка переносится в ODS как есть и отвечает на
+вопрос «когда строка приехала в хранилище», а не «когда её разобрали». В
+`ods.event` она же служит колонкой версии `ReplacingMergeTree` и схлопывает
+повтор доставки. `ods.order_snapshot` повтор не схлопывает: пакетный шаг
+заменяет целиком партицию `snapshot_date`.
+
+`created_at` и `updated_at` заказа к служебным колонкам хранилища не относятся.
+Они приезжают в сообщении как аудит строки в БД источника и в ODS разбираются в
+`DateTime64(3, 'UTC')`; ClickHouse их не создаёт и добавляет рядом собственную
+`_load_ts`. Совпадение слов «техническое время» не делает эти часы одной осью.
+
+Пакетной переобработки у событий в ODS нет: слой наполняют матвью, а не задание
+Airflow. Переделать разобранное руками можно вставкой из сырья с фильтром по
+`_load_ts` в пределах трёхсуточного окна; ничья по версии разрешается в пользу
+вставленного позже. Заказы, напротив, по построению перерабатываются дневными
+партициями пакетного шага.
 
 Имя согласовано с каноном служебных полей соседнего учебного стенда на
 Greenplum, чтобы словарь был общим у двух хранилищ; ведущее подчёркивание у
@@ -141,10 +150,10 @@ Greenplum, чтобы словарь был общим у двух хранил
 её же используют Fivetran, Airbyte и Stitch. С правилом выше это не спорит:
 запрещено совпадать с именами виртуальных колонок, а не носить подчёркивание.
 
-Идентификатора пачки загрузки (`_load_id`) пока нет. В STG и ODS данные приезжают
-потоком через матвью, у которого нет ни батча, ни `run_id`, и колонка была бы
-пустой формальностью. В слоях, которые наполняет Airflow, `run_id` появится
-по-настоящему — тогда и заведём, тем же стилем имени.
+Общего идентификатора пачки загрузки (`_load_id`) нет. У потока событий нет ни
+пачки, ни `run_id`, и колонка была бы пустой формальностью. Пакетный шаг заказов
+не делает её общей конвенцией: конкретный слой заведёт `run_id`, только когда у
+него появится названный читатель этой координаты.
 
 ## Часовые пояса