refactor(dm): уточнены ограничения DAG и пояснения SQL

- Зачем:
  - Ревью выявило неясные причины ограничений и защитных условий в учебном образце.
- Что:
  - Спекулятивный общий потолок задач заменен адресным лимитом размноженной замены с точным описанием OOM.
  - Объяснены нулевое значение непарного LEFT JOIN и опасность пустого DDS при замене партиций.
  - Добавлена ссылка на разбор области пересборки, а общий штамп про Context7 удален.
- Проверка:
  - make lint, make config-test, make smoke; успешный запуск dm_transform.

sql/dm/daily_traffic_rebuild.sql

@@ -15,6 +15,8 @@ INSERT INTO dm.daily_traffic_dist
 SELECT
     sessions.session_date,
     uniqExact(sessions.client_id),
+    -- При стендовом join_use_nulls=0 непарный UInt64 получает 0. Условие
+    -- не дает анонимной сессии превратиться в известного пользователя.
     uniqExactIf(identities.user_id, identities.user_id != 0),
     {load_id:String},
     now64(3, 'UTC')

sql/dm/revenue_daily_scope.sql

@@ -4,6 +4,8 @@
 -- изменить. Сам агрегат читает только DDS; ODS здесь нужен лишь для границ.
 -- Первый запуск и повтор после частичного отказа расширяют левую границу до
 -- первого дня оплаченных заказов, которого еще нет в витрине.
+-- Почему хвост начинается с первого пропуска и чем за это платит ODS,
+-- разобрано в sql/dds/order_scope.sql.
 --
 -- Файл кончается без точки с запятой: даг читает его одним запросом и ждет
 -- одну строку с границами.
@@ -31,5 +33,7 @@ WITH
 SELECT
     least(window_start, coalesce(first_missing_day, window_start)) AS first_day,
     window_end AS last_day
+-- Без ODS неизвестно окно. Без готового DDS донор останется пустым, а замена
+-- сотрет уже собранные дни выручки. Поэтому для прогона нужны оба источника.
 WHERE (SELECT count() FROM dds.order_v) > 0
     AND (SELECT count() FROM ods.order_dist) > 0