docs(superset): синхронизация доков и урока 6 под row-lineage

- Зачем:
  - после смены чарта на row-lineage пользовательская дока, README и урок 6
    описывали несуществующий «Data Quality Summary» и старый состав KPI;
    термин «зерно (grain)» использовался без пояснения.
- Что:
  - SUPERSET_DASHBOARD.md, README, урок 6 описывают «Rows by Layer (event)»,
    выровнен состав KPI/чартов; термин «зерно» поясняется в уроке простыми
    словами с якорем из данных (события 1000 / визиты 99).
  - термин выровнен на «визит» по CONTEXT.md (click_id = визит/сессия).
  - в спеку редизайна добавлена секция «Пересмотр после приёмки» как след решения.
- Проверка:
  - grep по «Data Quality Summary»/«Row Count» вне handoffs пуст.
  - визуальная вычитка изменённых разделов.

docs/course/lessons/06_superset_bi.md

@@ -121,12 +121,35 @@ http://localhost:8088/superset/dashboard/1/
 - динамика: `Events by Hour`, `Traffic by Device`;
 - география: `Geography Map`;
 - маркетинг: `UTM Effectiveness Table`, `Page Funnel`;
-- качество данных: `Data Quality Summary`.
+- прохождение строк по слоям: `Rows by Layer (event)`.
 
 `Conversion to /confirmation` считается как просмотры `/confirmation` / просмотры `/home`.
 Это page-funnel метрика, а не доля визитов: она совпадает с тем, как ниже устроен chart
 `Page Funnel`.
 
+`Rows by Layer (event)` показывает, сколько строк доходит до каждого слоя конвейера
+`STG → ODS → DDS → DM`. Прежде чем читать чарт, договоримся про одно слово.
+
+> **Зерно (grain), он же уровень гранулярности — это что считается одной строкой
+> таблицы.** У события зерно
+> «одно событие = одна строка» (ключ `event_id`), у визита — «один визит = одна
+> строка» (ключ `click_id`). Это разные зёрна: событий 1000, а визитов 99, потому
+> что в одном визите много событий. Складывать строки разного зерна в одно число
+> бессмысленно — это всё равно что сложить «штуки яблок» и «корзины яблок».
+
+Поэтому чарт держит **одно зерно — event**: берёт по одной канонической таблице
+событий на слой (`browser_raw → browser_event → event → v_events_enriched`), а не сумму
+по слою. Если просуммировать все таблицы слоя, в один столбец попадут таблицы разного
+зерна (события 1000 + визиты 99 + пустые error-таблицы) и получится «воронка потерь»,
+которой на самом деле нет.
+
+Шаг **1050 → 1000** на первом переходе — это не потеря данных, а дедупликация
+at-least-once потока по `event_id` в ODS (`ReplacingMergeTree`): в STG приехало 1050 строк,
+но уникальных `event_id` среди них — 1000 (часть событий Kafka доставила повторно). Дальше
+число стабильно. Настоящие проблемы качества (ошибки парсинга, осиротевшие события) на
+чистых демо-данных равны нулю и лежат в `dm.dq_summary` отдельными `check_name` — их
+разбирали уроки 3–4.
+
 ### Фильтр даты
 
 В демо-данных события датированы `2022-11-28`. В текущей конфигурации dashboard фильтр даты
@@ -139,7 +162,7 @@ http://localhost:8088/superset/dashboard/1/
 - или ручной диапазон вокруг `2022-11-28`.
 
 После этого нажми **Apply filters**. Теперь смотри на dashboard как аналитик: какие графики
-отвечают на бизнес-вопросы, а какие только показывают техническое качество данных.
+отвечают на бизнес-вопросы, а какие только показывают техническое устройство конвейера.
 
 ### Проверяем данные напрямую в ClickHouse
 
@@ -201,11 +224,12 @@ LEFT JOIN dds.click AS c ON c.click_id = e.click_id;
 | `dm.v_utm_effectiveness` | таблица по UTM-каналам |
 | `dm.v_top_pages_daily` | популярные страницы |
 | `dm.v_session_overview` | обзор сессий |
-| `dm.dq_summary` | сводка качества данных по слоям |
+| `dm.dq_summary` | метрики по слоям: строки (`total_rows`), ошибки, сироты |
 
 Открой [`sql/dm/40_dds_to_dm.sql`](../../../sql/dm/40_dds_to_dm.sql). Этот файл не пересчитывает
-все `dm.v_*`: VIEW создаются в DDL. Здесь batch-часть наполняет `dm.dq_summary`, чтобы dashboard
-мог показать качество данных после каждого прогона.
+все `dm.v_*`: VIEW создаются в DDL. Здесь batch-часть наполняет `dm.dq_summary` метриками по
+слоям (включая строку для слоя `dm`), чтобы dashboard мог показать прохождение строк по
+конвейеру после каждого прогона.
 
 ### `init_superset.py`: подключение и datasets
 
@@ -380,7 +404,7 @@ metadata Superset.
 | `make transform` | ClickHouse `dm.v_events_enriched` | `count() > 0` |
 | `make superset-init` | Superset → **Settings → Database Connections** | есть подключение `clickhouse_dwh` |
 | открыть **Datasets** | Superset UI | есть datasets `v_events_enriched`, `v_top_pages_daily`, `dq_summary` |
-| открыть dashboard | Superset UI | видны KPI, маркетинг, география и качество данных |
+| открыть dashboard | Superset UI | видны KPI, маркетинг, география и прохождение строк по слоям |
 | поставить **Date Range → No filter** | dashboard filters | графики не скрываются из-за даты `2022-11-28` |
 | поменять `row_limit` у `Page Funnel` на `3` и запустить `make superset-dashboard` | chart `Page Funnel` | не больше трёх страниц |
 | вернуть `row_limit` на `20` и запустить `make superset-dashboard` | chart `Page Funnel` | ограничение снова до 20 страниц |