docs(dds): спроектирован контракт dds.event_v — язык модели поверх ODS

- Зачем:
  - развилка #132 карты #127: витринам DM и сборке сессий нужен контракт
    события на языке бизнес-модели, первый пример правила «слой — это
    контракт, а не обязательно копия данных».
- Что:
  - создан docs/architecture/dds/event.md: представление над ods.event_v,
    имена модели (event_id, event_time в поясе счётчика, event_date
    переименованием), расшифровка device_category, скрыты VisitID, Sign,
    ecommerce и служебные колонки.
  - в README карта модели ведёт на event.md, развилка убрана из открытых
    решений; session.md ссылается на резолюцию судьбы VisitID.
- Проверка:
  - вычитка; относительные ссылки в docs/architecture/dds/ ведут на
    существующие файлы.

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

docs/architecture/dds/session.md

@@ -82,7 +82,7 @@
 смотрят через `dds.event_v`; сессия и по смыслу не финальна, пока день не
 прожит.
 
-Источник сборки — `dds.event_v`; его контракт решает развилка #132, сессии
+Источник сборки — `dds.event_v` ([контракт события](event.md)): сессии
 нужны от него ключи нарезки, тип события, страница, UTM и паспорт куки.
 Механика запуска — где собирается партиция и как подменяется на кластере —
 не входит: это устройство трансформаций (#134, этап 5).
@@ -95,9 +95,9 @@
 компенсация ошибок внутри одной куки за день; эталон в модель не тащим —
 строка сессии остаётся нашей, а не генераторной. Поштучное сопоставление
 границ — материал лабы, где менти разбирает найденное расхождение руками. Дом проверки —
-контур DQ этапа 4. Сверке нужен `VisitID`, а сборке сессий — нет; останется
-ли он в контракте `dds.event_v` или проверка пойдёт за ним в ODS — решает
-развилка #132.
+контур DQ этапа 4. Сверке нужен `VisitID`, а сборке сессий — нет; контракт
+`dds.event_v` его скрывает, и за эталоном проверка идёт в `ods.event_v`
+([контракт события](event.md)).
 
 ## Читатели