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/snapshot.md

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