feat(generator): потеря и дубль purchase (B, D) и счетчики описи

- Зачем:
  - трекер стенда был полным, и правило «деньги — по бэкенду» держалось
    на слове; классы B и D делают недосчет и пересчет трекера
    наблюдаемыми (этап 6, #184).
- Что:
  - подпоток BEACONS: точечная потеря purchase (~3%) и сюжетный дубль
    (~2%) швом после _purchases, с гарантией моста идентичностей и
    условием допуска дубля по паузе до следующего визита;
  - опись считает пять классов по приоритету спеки; фильтр
    classes_vs_inventory расширен, нулевой класс читается нулем;
  - fate.md, seeds.md, dm.md и orders/README.md приведены к имени
    BEACONS и строгому правилу допуска.
- Проверка:
  - make lint, make typecheck, make test (433 passed) и make inventory
    из generator/ — хеши слепков не изменились;
  - на стенде: make smoke, make check-clickhouse, make check-services
    зеленые; в dq_summary classes_vs_inventory и sessions_vs_reference
    pass, витрина сверки показывает lost_event и duplicate_event.

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

docs/architecture/dm.md

@@ -111,7 +111,7 @@
 
 Зерно — заказ. Покупки из `dds.event_v` сначала сворачиваются по
 `purchase_id[1]`: контракт источника обещает один номер и одну объявленную
-сумму, а отдельный счет событий оставляет будущий класс `duplicate_event`
+сумму, а отдельный счет событий оставляет класс `duplicate_event`
 наблюдаемым. Заказы приходят из `dds.order_v`. Обе стороны записаны
 подзапросами, затем соединены `FULL OUTER GLOBAL JOIN`: голая левая
 Distributed-таблица вернула бы каждый непарный заказ по разу с каждого шарда
@@ -176,8 +176,8 @@ Distributed-таблица вернула бы каждый непарный з
   `dds.session_v`;
 - `classes_vs_inventory`: ключ — `mismatch_class`, эталон — счётчик из
   `orders` в описи мира, объект — число заказов класса в
-  `dm.purchase_vs_orders_v`. Проверяются `match`, `cancelled` и
-  `amount_delta` только для покрытых описью закрытых дней;
+  `dm.purchase_vs_orders_v`. Проверяются `match`, `cancelled`, `lost_event`,
+  `duplicate_event` и `amount_delta` только для покрытых описью закрытых дней;
 - `revenue_daily_vs_dds`: ключ — `product_category` внутри дня. Сравниваются
   `orders`, `units`, `revenue` и `aov` с прямым агрегатом `dds.order_v`;
 - `purchase_vs_orders_vs_dds`: ключ — `order_id` внутри дня. Все деловые

docs/architecture/generator/seeds.md

@@ -30,7 +30,7 @@
         ├── TRAFFIC
         ├── COMMERCE
         ├── ORDERS
-        └── LATECOMERS — место будущей событийной стороны
+        └── BEACONS — потеря и повторная отправка событий
 ```
 
 Отрицательному дню нельзя отдать отрицательную позицию, поэтому предыстория

docs/architecture/orders/README.md

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

docs/architecture/orders/fate.md

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