docs(orders): нарезка укрупнена до семи файлов

Зачем: девять зон ломали правило «семь плюс-минус два» — оглавление
переставало помещаться в голову читателя, навигация мешала чтению.

Что: projection.md влит в snapshot.md («Заказ и его слепок»), mismatch.md —
в fate.md («Судьба заказа и расхождения»): каждая пара несла одну резолюцию
(#71 и #72). Выжили имена, на которые смотрят внешние ссылки; внутренние
перенацелены, индекс README обновлён.

Проверка: grep по репозиторию — упоминаний удалённых имён нет; обход
относительных ссылок набора — битых нет.

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

docs/architecture/orders/snapshot.md

@@ -1,8 +1,42 @@
-# Слепок и его доставка
+# Заказ и его слепок
 
 Резолюция развилки [«Генератор слепков: где живёт и чем связан с
 событиями»](https://git.dementev.space/ddmitry/clickstream-data-platform/issues/71).
 
+## Откуда берётся заказ
+
+Заказ и событие `purchase` — не два порождения, а две проекции одного факта
+мира. Корзина, цены, купон и номер заказа посчитаны торговой половиной
+дня-функции; заказная половина берёт заказы дня готовой структурой — вторым
+выходом `commerce`, — навешивает на них жизнь заказа и собирает слепок. В
+подпоток `COMMERCE` не добавляется ни одного нового броска: мир не сдвигается,
+согласованность двух источников не удерживается, а получается по построению.
+
+Следствия, которые уже решены соседями и здесь только связываются:
+
+- у всякого заказа изначально ровно одно событие `purchase`; заказ без события
+  в трекере — не отдельная порода, а класс B, и делает его событийная сторона
+  выбрасыванием события после присвоения номера
+  ([классы расхождений](fate.md));
+- номер заказа общий у обеих проекций: `order_id` = клиентский `purchaseID`,
+  читаемый номер «день и порядковый номер покупки» ([спека
+  генератора](../../specs/2026-08-01-generator.md), раздел 9); нумеруются все
+  покупки, дошедшие до потока дня, — до всяких потерь;
+- скидка заказа выводится из промокода события по таблице «код → скидка» —
+  числу мира, которое этап 3 берёт готовым (спека генератора, разделы 8 и 9).
+
+В модели строка заказа в базе источника создаётся синхронно с покупкой,
+поэтому день рождения заказа и день создания строки совпадают.
+
+Отклонено: *выводить заказ разбором собственного вывода* (`purchaseID`, сырой
+`ecommerce`) — бэкенд стал бы читателем трекера ровно там, где стенд учит, что
+это разные источники; *независимая модель бэкенда* (заказ первичен, событие —
+эхо) — кто купил, решает воронка, а воронка — это трафик, то есть опрокидывание
+всего генератора; *слепок собирает SQL стенда из событий* — второй источник
+исчезает вместе с уроком «две версии правды».
+
+## Слепок и его доставка
+
 **Запуск.** Третья команда того же пакета — `snapshot --day D [--days N]`,
 свой приёмник, топик `orders`. Два источника — два запуска: трекер и бэкенд
 видны глазами как два производителя, каждый со своим топиком. Один прогон с