docs(dds): спроектирована модель заказа в DDS и заведён набор доков слоя

- Зачем:
  - развилка #130 карты #127: заказу нужен объект в DDS — зерно, состав,
    движок и судьба служебных колонок; резолюции этапа 4 нужен дом в git.
- Что:
  - создан набор docs/architecture/dds/ по ADR 0011: README с картой
    модели и правилами слоя, order.md с моделью заказа — зерно «заказ в
    текущем состоянии», позиции массивами, MergeTree с заменой партиций,
    свои _load_id/_load_ts вместо ярлыков ODS (закрывает наследство #85);
  - указатели на модель добавлены в orders/README.md, orders/ingestion.md
    и storage.md.
- Проверка:
  - только документы; относительные ссылки сверены с деревом docs/.

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

docs/architecture/orders/README.md

@@ -40,6 +40,8 @@
   `INSERT SELECT` в типизированный ODS и таблицу ошибок; `ods.order`
   принимает версии заказа на `ReplacingMergeTree(updated_at)` —
   [приём из Kafka в ODS](ingestion.md).
+- **Дальше заказ живёт моделью DDS** — уже по хранилищную сторону границы,
+  в наборе слоя: [модель заказа](../dds/order.md).
 - **Стартовый мир отправляет семь слепков** (дни 0…6): у последнего прожитого
   дня клики есть, а заказов нет, и график выручки дозаполняется по ходу
   мира — [заказы в стартовом мире](start-world.md).

docs/architecture/orders/ingestion.md

@@ -129,8 +129,9 @@ JSON-объектом с точным набором ключей: `order_id`, `
 
 Это представление остаётся ответственностью ODS: оно скрывает механику чтения
 версий, но не строит бизнес-модель. DDS читает `ods.order_v` и отдельно решает,
-какие сущности, связи и производные признаки ему нужны. Нужен ли `_load_id`
-выше ODS, решается вместе с DDS, а не здесь.
+какие сущности, связи и производные признаки ему нужны. Судьба служебных
+колонок выше ODS решена вместе с моделью DDS: чужие ярлыки туда не переезжают
+([модель заказа](../dds/order.md)).
 
 ## Одно чтение Kafka