docs(orders): устройство заказов переехало в живой набор architecture/orders

Зачем: собранная спека заказов стала базовой документацией сервиса, а
жанр спеки-события ей мал: дата в имени врёт, целиком в контекст агента
она не влезает, а трекер с резолюциями долговечным хранилищем не
считается. Решение владельца — держать детальное устройство компонента
связным набором живых документов (ADR 0011) и совместить переезд с
проходом на вычитание (#84).

Что: docs/architecture/orders/ — индекс README и файлы по частям
устройства: проекция, слепок и доставка, судьба, классы расхождений,
опись, мост к склейке, стартовый мир, правила кода; спека приёма
переехала в ingestion.md без содержательных правок. Резы вычитания по
итогам двух слепых линий: тела разделов о проводе и приёме сведены к
указателям на мастер-спеку, исследование формата и ADR (порядок строк
слепка — единственное правило, оставшееся на месте); замеры канонического
зерна и повторы-пояснения срезаны; списки отклонённых вариантов сохранены
как долговечная запись. Датированные файлы удалены, ссылки из мастер-спеки,
спеки генератора, ADR 0008/0010, исследования формата и storage.md
перенацелены; раздел «Структура» AGENTS.md дополнен правилом подпапки.

Проверка: grep по репозиторию не находит ссылок на удалённые файлы;
все относительные ссылки внутри набора разрешаются в существующие файлы;
впереди холодная сверка «ни одно решение не потеряно» и приёмка #88.

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

docs/architecture/orders/projection.md

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