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

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

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

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

Refs: #249

docs/architecture/storage.md

@@ -95,20 +95,24 @@ DDS: представление читает события ODS.
 Само совпадение ключей еще не гарантирует локального выполнения запроса
 через представления — пример есть в [описании `daily_traffic`](dm.md#dmdaily_traffic_v).
 
-Для дневной пересборки DDS и DM используют донор — служебную таблицу,
-в которой готовят результат перед заменой партиций. Например,
-`dds.order_stage_rep` объявлена через `AS dds.order_rep`, а запись
-в нее идет через `dds.order_stage_dist` с тем же `cityHash64(order_id)`.
-У цели и донора должны совпадать структура, ключи партиции и сортировки,
-первичный ключ и политика хранения. Эти требования сверены через Context7
-с [документацией ClickHouse](https://clickhouse.com/docs/sql-reference/statements/alter/partition#replace-partition)
-для используемой схемы на ClickHouse 26.3. Поэтому донор объявлен через
-`AS` цели с совпадающими ключами. DDL показан в
+Для дневной пересборки DDS и DM результат сначала записывают
+в промежуточную таблицу. Основная таблица в это время остается доступна
+для чтения с прежними данными. Например, заказы записываются через
+`dds.order_stage_dist` в `dds.order_stage_rep`, затем ее дневные разделы
+заменяют разделы основной `dds.order_rep`.
+
+У промежуточной и основной таблиц должны совпадать структура, ключи
+партиции и сортировки, первичный ключ и политика хранения. Поэтому
+`dds.order_stage_rep` объявлена через `AS dds.order_rep` с совпадающими
+ключами. Требования сверены через Context7 с
+[документацией ClickHouse](https://clickhouse.com/docs/sql-reference/statements/alter/partition#replace-partition)
+для схемы на ClickHouse 26.3. DDL показан в
 [`sql/ddl/45-dds-tables.sql`](../../sql/ddl/45-dds-tables.sql).
 
-`REPLACE PARTITION` копирует готовую партицию между локальными таблицами
-на каждом шарде; заново распределять строки по ключу цели эта операция
-не будет. Поэтому донор должен сразу иметь ту же раскладку, что и цель.
+Промежуточная таблица должна также распределять строки по тому же ключу,
+здесь — `cityHash64(order_id)`. `REPLACE PARTITION` копирует раздел между
+локальными таблицами каждого шарда и не перераспределяет строки.
+Поэтому уже в промежуточной таблице заказ должен находиться на нужном шарде.
 Перед заменой вставка с `distributed_foreground_insert = 1` дожидается
 доставки данных на шарды.