docs(warehouse): объяснены расчет строк и замена дневных разделов

Зачем: выражения «собираются в донор» и «публикуются дни» требовали
знать устройство конвейера до чтения объяснения.

Что: описаны назначение промежуточных таблиц и последовательность
расчета, записи и замены разделов. Перечитаны остальные объяснения:
выбор дней, разворачивание позиций заказа, проверка сессий и повтор запуска.

Проверка: make lint, git diff --check, локальные ссылки и якоря.
SQL без комментариев и AST обоих дагов без строк документации не изменились.

Refs: #249

docs/architecture/dds/session.md

@@ -17,10 +17,11 @@
 `EventDate` источника, дата по часовому поясу счетчика. У всех событий
 одной сессии она одинакова. Пересчитывать ее из времени UTC не нужно.
 
-Оба окна нарезки используют порядок `(event_time, event_id)`: при равном
-времени события идут по идентификатору. Одинаковый порядок нужен, чтобы
-признак начала визита и накопленный номер визита относились к одним
-и тем же событиям.
+SQL рассчитывает границы визитов двумя оконными функциями: первая отмечает
+начало нового визита, вторая по этим отметкам присваивает событиям номер
+визита. Обе используют порядок `(event_time, event_id)`: при равном времени
+события идут по идентификатору. Иначе два расчета могли бы по-разному
+упорядочить события и отнести отметку начала к разным строкам.
 
 ## Идентификатор
 
@@ -73,24 +74,28 @@
 Три SQL-файла выполняются последовательно в группе `session` дага
 `dds_transform`:
 
-1. `session_scope.sql` находит первый день событий, которого еще нет
-   в таблице сессий. Последний день для сборки — первый день событий ODS
-   плюс `world_position` минус один. Так в расчет попадают только полностью
+1. `session_scope.sql` находит первую дату событий, за которую еще нет
+   сессий. Последний день для расчета — первый день событий ODS
+   плюс `world_position` минус один; `world_position` — номер следующего
+   дня для генерации. Так в расчет попадают только полностью
    прожитые дни. При пустом ODS запрос не возвращает строк и задача падает;
    если пропущенных прожитых дней нет, `first_day` равен `NULL` и группа
    пропускается.
-2. `session_rebuild.sql` очищает `dds.session_stage_rep` и собирает весь
-   выбранный диапазон в `dds.session_stage_dist`. Это донор — служебная
-   таблица для подготовки результата до публикации. Вставка ждет доставки
+2. `session_rebuild.sql` очищает промежуточную таблицу
+   `dds.session_stage_rep`. Затем рассчитывает сессии выбранных дней
+   и записывает строки через `dds.session_stage_dist`. Пока идет расчет,
+   в основной таблице остаются прежние данные. Вставка ждет доставки
    строк на шарды благодаря `distributed_foreground_insert = 1`.
-3. `session_replace.sql` заменяет каждый день в `dds.session_rep` партицией
-   донора. Для каждого дня Airflow создает отдельную задачу `replace`.
+3. `session_replace.sql` заменяет в `dds.session_rep` раздел за каждый
+   выбранный день готовым разделом `dds.session_stage_rep`. Для каждого
+   дня Airflow создает отдельную задачу `replace`.
 
-В обычном ходе сессии прожитого дня больше не меняются. Если пропущен ранний
+Когда все события завершенного дня приняты в ODS, их набор на стенде
+больше не меняется. Поэтому готовые сессии обычно не пересчитываются. Если пропущен ранний
 день, диапазон включает и все последующие прожитые дни, даже уже собранные.
-Поиск по наличию даты не обнаружит неполный день, у которого часть строк
-сохранилась. Условия повторного запуска и границы атомарности замены
-описаны в [справочнике конвейера](../etl.md#идемпотентность).
+Если за день сохранилась хотя бы одна сессия, поиск пропущенных дней
+не обнаружит потерю остальных. Условия повторного запуска и замены
+разделов описаны в [справочнике конвейера](../etl.md#идемпотентность).
 
 Сессий еще идущего дня в модели нет; его события доступны через
 `dds.event_v`. Перед выбором дней даг ждет завершения доставки событий
@@ -103,10 +108,10 @@
 из `ods.event_v`. Эталон читается из ODS, потому что `dds.event_v`
 скрывает `VisitID`.
 
-Нулевое число расхождений подтверждает совпадение счета, но не всех
-границ и атрибутов сессий. Две ошибки внутри одного посетителя и дня
-могут сохранить число визитов. Поэтому в заданиях вы дополнительно
-сопоставляете границы сессий по исходным событиям и проверяете страницы,
+Нулевое число расхождений подтверждает только число сессий каждого
+посетителя за день. Например, ошибочное объединение двух визитов
+и разделение другого на два сохранят их общее число. Поэтому в заданиях
+вы дополнительно сопоставляете границы сессий по исходным событиям и проверяете страницы,
 UTM, устройство и город.
 
 ## Читатели