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

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

docs/architecture/etl.md

@@ -5,10 +5,9 @@
 движки, что именно пересобирается — живут в доках слоя
 ([карта модели DDS](dds/README.md)); здесь — только конвейер.
 
-Спека обещала `etl_pipeline` этапом 5 — он понадобился раньше. Конвейер
-рождается этапом 4, и временного в нём ничего нет: дневная сборка вперёд
-останется и после. Этапу 5 достаётся его законный предмет — партиционная
-переобработка, умение переиграть произвольный прошлый день по команде.
+Дневная сборка вперёд появляется на этапе 4 и остаётся основным режимом
+конвейера. На этапе 5 к ней добавляется партиционная переобработка: запуск
+произвольного прошлого дня по команде.
 
 ## Форма
 
@@ -47,25 +46,28 @@
 Поэтому один и тот же запуск одинаково верен из триггера, с кнопки менти и
 после падения, а разгону на семь дней хватает одного прогона.
 
-Окно заказов — **дни, которые нёс последний слепок**. Называет их сам
-источник: `snapshot_date` выжившей строки равен последнему слепку, в котором
-заказ был, поэтому оба края окна трансформация читает прямо из ODS
-([ADR 0014](../adr/0014-order-version-snapshot-date.md)). Своего числа окна у
-стенда нет, и расходиться с миром нечему.
+Окно заказов задаёт последний слепок, наблюдаемый в ODS. У каждого заказа
+`snapshot_date` равен последнему слепку, в котором источник его показал.
+Трансформация выбирает строки с максимальной `snapshot_date` и берёт среди них
+минимальный и максимальный `order_date`. Это границы дней, состояние которых
+источник ещё может изменить
+([ADR 0014](../adr/0014-order-version-snapshot-date.md)). Кроме живого окна,
+трансформация закрывает пропуски: находит самый ранний день, представленный в
+ODS и ещё не собранный в DDS, затем при необходимости расширяет до него левую
+границу.
 
 Позиция мира заказам не отвечает: она говорит, какой день прожит, а не какой
 доехал. Прогон дня D везёт слепок дня D − 1, да и ставится позиция раньше
 трансформации, так что после неудачного приёма обгоняет хранилище. Слой обязан
 считать объём по тому, что у него есть, а не по тому, что мир о себе заявляет.
 
-У сессий всё наоборот: им отвечает только позиция, потому что вопрос у них
-другой. Им нужен не день, о котором рассказал источник, а день, который мир
-**прожил**: события живой день от прожитого не отличают — и посреди дня D,
-и сразу после его конца позднейший день событий равен D. Соберись сессии посреди
-дня, визит, начатый в 23:50, остался бы обрезанным навсегда: замёрзший день слой
-не пересобирает.
-Отсюда правило — последний прожитый день равен первому дню событий плюс позиция
-минус один ([`sql/dds/session_scope.sql`](../../sql/dds/session_scope.sql)).
+Для сессий границу задаёт `world_position`: она отличает полностью прожитый
+день от ещё идущего. Сами события этой границы не показывают: и посреди дня D,
+и сразу после его конца их позднейший день равен D. Если собрать сессии посреди
+дня, визит, начатый в 23:50, останется обрезанным: завершённый день слой
+повторно не собирает. Поэтому последний прожитый день равен первому дню
+событий плюс позиция минус один
+([`sql/dds/session_scope.sql`](../../sql/dds/session_scope.sql)).
 Оговорка про «доехал» остаётся в силе и здесь: за хвост потока отвечает не
 позиция, а «Готовность источника».