feat(generator): заказы дня — проекция покупок с деньгами магазина

- Зачем:
  - тикет #90: второй источник должен смотреть на торговую половину дня
    глазами бэкенда — заказ есть проекция покупки, а не второе порождение;
    учебный результат — два источника согласованы по построению, а не
    сверкой.
- Что:
  - `commerce` отдаёт вторым выходом покупки дня: номер заказа, корзину,
    выручку клиента, промокод и человека за кукой; новых бросков в
    подпоток `COMMERCE` не добавилось, события дня не сдвинулись.
  - заведена заказная сторона: подпоток `ORDERS` на позиции 2 дерева зерна
    (прежнее мёртвое имя `DISCREPANCIES`), ветвление — по дню рождения
    заказа; `LATECOMERS` не тронут, его наполнит этап 6.
  - новый модуль `orders.py`: деньги заказа целыми копейками —
    `items_total` из корзины, `discount` по таблице «код → скидка»
    (округление вниз), `delivery` броском по таблице весов на полную длину
    дня, `total` = `items_total` − `discount` + `delivery`.
  - план состава завёл `person_id` — последним броском когорты, после
    паспортов: вторая кука пары повторяет ID своего человека, заказ
    показывает его как `user_id`, в событие Метрики он не попадает.
  - `world`: окно изменяемости `ORDER_WINDOW_DAYS` = 7 рядом с D0 и поясом,
    черновая таблица стоимости доставки.
  - слепок дня в тестах сторожит обе половины: заказы сравниваются наравне
    с потоком событий.
  - доки: имя подпотока заказной стороны и состав денег заказа записаны в
    `docs/architecture/orders`, README генератора знает про новый модуль.
- Проверка:
  - из `generator/`: make lint, make typecheck, make test (417 тестов);
    в корне — make lint.
  - опись мира не покраснела: байты восьми дней те же, заказная сторона
    события не сдвинула.

Closes #90

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/architecture/orders/README.md

@@ -49,8 +49,10 @@
 
 ## Открытые решения
 
-- **Имена подпотоков сторон судьбы** — при реализации; из мёртвых имён никто
-  не бросает, переименование ничего не сдвигает (#72).
+- **Имя подпотока событийной стороны** — вместе с её содержимым на этапе 6;
+  из мёртвых имён никто не бросает, переименование ничего не сдвигает (#72).
+  Заказная сторона уже названа — подпоток `ORDERS` ([судьба
+  заказа](fate.md)).
 - **Конкретные веса и доли** — таблицы исходов, моментов, задержки опоздания,
   доли классов, стоимость доставки — калибровка при реализации; финальная
   фиксация чисел — пересборка эталонного мира, этап 7. При пересборке правки

docs/architecture/orders/fate.md

@@ -14,10 +14,13 @@
 не двигает хеши событий, правка событийной не двигает байты слепка, и по
 покрасневшим хешам видно, какую сторону трогали. Прежние имена `DISCREPANCIES`
 и `LATECOMERS` решения не переживают — они названы по классам витрины, а
-компонент называет часть мира; новые стороны занимают те же позиции, имена —
-при реализации. Отклонено: *один компонент на всю судьбу* — правка событийной
-механики молча меняла бы байты слепка; *компонент на класс* — пять имён под
-ручки калибровки, которые крутятся разом.
+компонент называет часть мира; новые стороны занимают те же позиции.
+Заказная сторона названа при реализации — подпоток `ORDERS` на позиции 2;
+событийная получит имя вместе с содержимым на этапе 6, до тех пор позиция 3
+занята мёртвым именем прежней нарезки. Отклонено: *один компонент на всю
+судьбу* — правка событийной механики молча меняла бы байты слепка;
+*компонент на класс* — пять имён под ручки калибровки, которые крутятся
+разом.
 
 **Правило формы, без которого разделение не работает: броски заказной стороны
 делаются на полную длину дня, а не на отобранных заказах.** Иначе длина броска

docs/architecture/orders/snapshot.md

@@ -28,6 +28,14 @@
 В модели строка заказа в базе источника создаётся синхронно с покупкой,
 поэтому день рождения заказа и день создания строки совпадают.
 
+**Деньги заказа** складываются целыми копейками: `items_total` — сумма
+позиций, посчитанная торговой половиной, то же число, что уехало клиентским
+`purchaseRevenue`; `discount` — процент промокода от неё, округлённый вниз;
+`delivery` — бросок заказной стороны по таблице целых весов, единственные
+деньги заказа, которых нет ни в одном событии; `total` = `items_total` −
+`discount` + `delivery`. Отсюда и правило витрин «деньги считаем по
+бэкенду»: про скидку и доставку клиент не знает вовсе.
+
 Отклонено: *выводить заказ разбором собственного вывода* (`purchaseID`, сырой
 `ecommerce`) — бэкенд стал бы читателем трекера ровно там, где стенд учит, что
 это разные источники; *независимая модель бэкенда* (заказ первичен, событие —