feat(dds): добавлена модель сессии и нарезка визитов окнами

Зачем:
- Дать слою расчётную сущность, которой в потоке нет: стенд режет визиты сам,
  а VisitID генератора остаётся эталоном самопроверки.
- Отделить прожитый день от живого — иначе визит, начатый в 23:50, замёрз бы
  обрезанным навсегда: пересобирать замёрзший день слой не станет.

Что:
- Добавлены dds.session_rep/_dist, двойник-донор dds.session_stage_rep/_dist и
  публичный договор dds.session_v.
- Нарезка стоит на двух окнах: первое ставит шов там, где пауза длиннее
  тридцати минут, второе считает нарастающий итог швов — номер визита. Границу
  суток держит разбиение окна, отдельной проверки ей не нужно.
- Порядок в окнах полный, по метке времени и event_id: сортировок две, и при
  равных метках они разошлись бы, разорвав сессию надвое.
- Объём прогона считается от первой дыры в слое по последний прожитый день;
  прожитый день выводится из позиции мира и первого дня событий. Собирать
  нечего — группа задач пропускается, а не зеленеет впустую.
- В dds_transform появилась группа session рядом с заказом; зависимости по
  данным между ними нет.
- Потолок max_active_tasks: размноженная замена без него выносит планировщика
  за отведённые ему 640 МиБ.
- parallel_distributed_insert_select у сессий не назначается вслух — ключ
  шардирования у источника и цели один по контракту ко-локации.
- Записано, что позиция отвечает за «прожит», а не за «доехал»: сторож хвоста
  потока приезжает отдельным тикетом.

Проверка:
- make lint
- make smoke (21 проверка), make check-clickhouse (10), make check-services
- Стартовый мир, пересобранный с нуля: 79367 сессий за восемь дней;
  расхождение с uniqExact(VisitID) по паре «кука × день» — ноль; все 401185
  событий ровно в одной сессии; session_id уникальны.
- Ни одной паузы длиннее тридцати минут внутри сессии и ни одной пары соседних
  визитов куки, разделённой меньшим промежутком.
- Повтор после DROP PARTITION ALL: те же session_id и то же содержимое строк.
- Снесённая руками партиция 2026-06-04: следующий прогон взял хвост от неё,
  дни до дыры не тронуты.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/architecture/dds/session.md

@@ -73,15 +73,18 @@
 шарде, поэтому сессионизация локальна по природе — капкан смены ключа при
 вставке, который дока хранилища обещает сборкам DDS, у сессий не стреляет.
 
-Сборка — дневной батч после прихода слепка заказов: хранилище выше ODS по
-смыслу батчевое, раз второй источник приходит раз в сутки. К этому моменту
-события дня полны, и сессии только что прожитого дня собираются один раз и
-целиком; идемпотентность держит замена партиции. В отличие от заказов, где
-батч пересобирает до K «дышащих» дней, у сессий пересобирается только одна
-партиция: день самодостаточен и замерзает сразу (правило спеки, раздел 6).
-Внутри живого дня модель сессии про сегодня честно молчит — «сегодня»
-смотрят через `dds.event_v`; сессия и по смыслу не финальна, пока день не
-прожит.
+Сборка — дневной батч: хранилище выше ODS по смыслу батчевое, раз второй
+источник приходит раз в сутки. Собирается день, который мир уже прожил, и
+собирается один раз и целиком; какой день прожит, слой спрашивает у позиции
+мира ([дневной конвейер](../etl.md), «Объём прогона»). Идемпотентность держит
+замена партиции. В отличие от заказов, где батч пересобирает до K «дышащих»
+дней, у сессии дышащего окна нет: прожитый день самодостаточен (правило
+спеки, раздел 6). Второй раз он соберётся только
+вынужденно — когда упавшая замена оставила позади дыру и хвост от неё накрыл
+соседние дни. Дней в одном прогоне при этом бывает несколько — столько,
+сколько мир успел прожить без слоя. Внутри живого дня
+модель сессии про сегодня честно молчит — «сегодня» смотрят через
+`dds.event_v`; сессия и по смыслу не финальна, пока день не прожит.
 
 Публичная поверхность — `dds.session_v`: обычное представление с явным
 списком деловых и собственных служебных колонок над `dds.session_dist`.

docs/architecture/etl.md

@@ -40,8 +40,8 @@
 ## Объём прогона
 
 Параметров у конвейера нет: объём он выводит сам из `world_position` и
-состояния слоёв. Сессии догоняют хвост — от последнего собранного дня до
-последнего прожитого; заказы пересобирают дышащее окно K и тот же хвост; карта
+состояния слоёв. Сессии догоняют хвост — от первого несобранного дня по
+последний прожитый; заказы пересобирают дышащее окно K и тот же хвост; карта
 идентичностей пересчитывается целиком; правила витрин — у
 [слоя DM](dm.md).
 Поэтому один и тот же запуск одинаково верен из триггера, с кнопки менти и
@@ -56,6 +56,16 @@
 неудачного приёма она обгоняет хранилище. Слой обязан считать объём по тому,
 что у него есть, а не по тому, что мир о себе заявляет.
 
+У сессий всё наоборот: им отвечает только позиция, потому что вопрос у них
+другой. Им нужен не день, о котором рассказал источник, а день, который мир
+**прожил**: события живой день от прожитого не отличают — и посреди дня D, и
+сразу после его конца позднейший день событий равен D. Соберись сессии посреди дня, визит, начатый в
+23:50, остался бы обрезанным навсегда: замёрзший день слой не пересобирает.
+Отсюда правило — последний прожитый день равен первому дню событий плюс позиция
+минус один ([`sql/dds/session_scope.sql`](../../sql/dds/session_scope.sql)).
+Оговорка про «доехал» остаётся в силе и здесь: за хвост потока отвечает не
+позиция, а «Готовность источника».
+
 Ярлыки доставки — `snapshot_date`, `_load_id`, `_load_ts` — не отвечают тоже, и
 это свойство ODS, а не недосмотр: слой схлопывает доставки, сохраняя деловые
 версии, поэтому у заказа, который не менялся, ярлык выжившей строки достаётся
@@ -67,14 +77,18 @@
 
 ## Готовность источника
 
-Первый шаг `dds_transform` — дождаться, пока хвост топика `hits` дожёван:
-отставание его потребителей нулевое (`system.kafka_consumers`). Зелёный
-приём заказов о событиях не говорит ничего — топики разные и потребители
-разные. В живом режиме зазор ничтожен, но в пакетном генератор выстреливает
-дни в топик быстрее, чем чтец их прожёвывает, и сессии собрались бы по
-недожёванному дню. DQ-сверка такой день подсветит, но починить его до
+Первым шагом `dds_transform` обязан дождаться, пока хвост топика `hits`
+дожёван: отставание его потребителей нулевое (`system.kafka_consumers`).
+Зелёный приём заказов о событиях не говорит ничего — топики разные и
+потребители разные. В живом режиме зазор ничтожен, но в пакетном генератор
+выстреливает дни в топик быстрее, чем чтец их прожёвывает, и сессии собираются
+по недожёванному дню. DQ-сверка такой день подсветит, но починить его до
 этапа 5 нечем: профилактика дешевле ремонта, которого ещё нет.
 
+Шага этого в даге ещё нет — он приезжает отдельным тикетом (#156), и до тех
+пор дыра открыта: сессии считают день прожитым по позиции мира, а хвост потока
+не стережёт никто. На приёмке отставание смотрят руками.
+
 ## Идемпотентность
 
 Партиция не заменяется простой вставкой. День собирается в таблицу-двойник —

docs/architecture/storage.md

@@ -16,8 +16,9 @@ keeper, Kafka, каркас сервисов. Этап 2 собран: в `sql/d
 CSV-файла. Живёт он вне цепочки слоёв, в зоне `dic`, и читает не файл, а
 подложку над ним ([ADR 0012](../adr/0012-dictionary-home.md)). Этап 4 начат
 публичным договором события `dds.event_v` над точным состоянием ODS, а следом
-получил первую физическую модель слоя — заказ: его пересобирает заменой
-партиций даг `dds_transform`.
+получил две физические модели слоя — заказ и сессию: их собирает заменой
+партиций даг `dds_transform`. Сессия среди них особая: в потоке такой сущности
+нет, стенд режет её из событий сам.
 Дальше по тексту устройство описано так, как оно проектируется; построенное от
 заложенного отличает карта таблиц в конце.
 
@@ -518,8 +519,8 @@ SQL-файлы исполняет штатный `SQLExecuteQueryOperator`. Пр
 | `20-ods-tables.sql` | типизированное событие, версии заказа и обе таблицы ошибок |
 | `30-ods-views.sql` | актуальные события, текущие заказы и матвью разбора в ODS |
 | `40-stg-views.sql` | матвью приёма: чтец в сырьё |
-| `45-dds-tables.sql` | физическая модель заказа и таблица-двойник, донор её партиций |
-| `50-dds-views.sql` | публичные договоры события и заказа на языке модели DDS |
+| `45-dds-tables.sql` | физические модели заказа и сессии, доноры их партиций |
+| `50-dds-views.sql` | публичные договоры события, заказа и сессии на языке модели DDS |
 
 Справочники идут сразу за базами: зона `dic` не зависит ни от одного слоя, и
 правила порядка слоёв к ней не применяются.
@@ -581,6 +582,9 @@ SQL-файлы исполняет штатный `SQLExecuteQueryOperator`. Пр
 | `dds` | `dds.order_rep` / `_dist` | заказ в текущем состоянии, партиция — день заказа |
 | `dds` | `dds.order_stage_rep` / `_dist` | двойник заказа: в нём день собирается перед заменой партиции |
 | `dds` | `dds.order_v` | публичный договор заказа |
+| `dds` | `dds.session_rep` / `_dist` | визит, нарезанный слоем; партиция — день сессии |
+| `dds` | `dds.session_stage_rep` / `_dist` | двойник сессии: в нём день собирается перед заменой партиции |
+| `dds` | `dds.session_v` | публичный договор сессии |
 | `dic` | `dic.products_file` | чтец CSV-каталога, общего с генератором |
 | `dic` | `dic.products` | словарь товаров поверх подложки |
 
@@ -588,10 +592,11 @@ SQL-файлы исполняет штатный `SQLExecuteQueryOperator`. Пр
 `INSERT SELECT` одной задачи `parse_batch` из файла
 `sql/ods/order_parse.sql`.
 
-В слое DDS построены событие и заказ, и устроены они намеренно по-разному:
-событие остаётся представлением над ODS, заказ получил физическую модель.
-Сессии, карту идентичностей и слой DM принесут следующие тикеты этапа. Их
-состав задан разделом 7 мастер-спеки и переносится сюда по мере постройки.
+В слое DDS построены событие, заказ и сессия, и устроены они намеренно
+по-разному: событие остаётся представлением над ODS, у заказа и сессии —
+физические модели. Карту идентичностей и слой DM принесут следующие тикеты
+этапа. Их состав задан разделом 7 мастер-спеки и переносится сюда по мере
+постройки.
 
 ## Что проверено