docs(dds): дописаны следствия ключей сессии — локальность и судьба VisitID

Зачем: две находки горячего ревью #131 уровня решения, принятые владельцем.

Что: в «Движок и наполнение» — следствие совпадения ключа шардирования с
событиями: сессионизация локальна по природе, капкан смены ключа у сессий
не стреляет; в «Сверку с эталоном» — зацепка для развилки #132: VisitID
нужен сверке, но не сборке, его дом решает контракт dds.event_v.

Проверка: вычитка; утверждение о локальности сверено с разделом
«Раскладка по шардам» доки хранилища.

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

docs/architecture/dds/session.md

@@ -68,6 +68,9 @@
 ключ сортировки — кука и начало сессии, шардирование распределённой таблицы —
 `cityHash64(ClientID)`, тем же выражением, что у событий, — ко-локация с
 `dds.identity_map` ([дока хранилища](../storage.md), «Раскладка по шардам»).
+Совпадение ключа с событиями не случайно: все события куки лежат на одном
+шарде, поэтому сессионизация локальна по природе — капкан смены ключа при
+вставке, который дока хранилища обещает сборкам DDS, у сессий не стреляет.
 
 Сборка — дневной батч после прихода слепка заказов: хранилище выше ODS по
 смыслу батчевое, раз второй источник приходит раз в сутки. К этому моменту
@@ -92,7 +95,9 @@
 компенсация ошибок внутри одной куки за день; эталон в модель не тащим —
 строка сессии остаётся нашей, а не генераторной. Поштучное сопоставление
 границ — материал лабы, где менти разбирает найденное расхождение руками. Дом проверки —
-контур DQ этапа 4.
+контур DQ этапа 4. Сверке нужен `VisitID`, а сборке сессий — нет; останется
+ли он в контракте `dds.event_v` или проверка пойдёт за ним в ODS — решает
+развилка #132.
 
 ## Читатели