docs(course): сквозной ревью — правки консистентности уроков 2/3/5 и OPERATIONS

- Зачем:
  - сквозной ревью курса нашёл расхождения учебного текста с реальным выводом
    стенда и один баг в операторских доках — менти увидел бы не то, что в уроке.
- Что:
  - урок 2: порядок строк «Статистики ODS» выровнен под фактический вывод
    run_batch.sh (4 основных таблицы, затем 4 *_errors); снято «по строчкам».
  - урок 3: добавлено пояснение, что check_date — это today() из витрины
    (у менти будет своя дата, не как в примере).
  - урок 5: «должно быть не в Alerting» → «в состоянии Normal (не Alerting)».
  - OPERATIONS.md: несуществующий FULL=1 заменён на реальный knob LIMIT=50
    (по умолчанию полный объём — подтверждено load_kafka_data.sh:27,128).
- Проверка:
  - git diff показывает 4 файла, +9/-6; grep 'FULL=' по docs/ пуст.
  - порядок таблицы сверен с run_batch.sh:111-118; today() — sql/dm/40_dds_to_dm.sql:105.

docs/OPERATIONS.md

@@ -10,7 +10,7 @@
 - `make down` (остановить и удалить контейнеры/сети проекта)
 - `make clean` (полная очистка: `down -v --remove-orphans`)
 - `make ddl` (применяет SQL из `sql/ddl/00_databases.sql` и `sql/ddl/*/*.sql` в ClickHouse)
-- `make data` (пересоздаёт топики и заливает небольшой срез данных в Kafka; полный режим — `FULL=1 make data`)
+- `make data` (пересоздаёт топики и заливает данные в Kafka; по умолчанию полный объём, срез — `LIMIT=50 make data`)
 - `make transform` (запускает batch-процесс ODS -> DDS -> DM)
 - `make superset-init` (повторная инициализация Superset: подключение к ClickHouse, датасеты, дашборд)
 - `docker compose ps`

docs/course/lessons/02_stg_to_ods.md

@@ -102,17 +102,17 @@ make transform           # батч STG → ODS → DDS → DM (нас инте
 Статистика ODS:
    ┌─table──────────────────────┬─rows─┐
    │ ods.browser_event          │   50 │
-   │ ods.browser_event_errors   │    0 │
    │ ods.location_event         │   50 │
-   │ ods.location_event_errors  │    0 │
    │ ods.device_by_click        │   26 │
-   │ ods.device_by_click_errors │    0 │
    │ ods.geo_by_click           │   26 │
+   │ ods.browser_event_errors   │    0 │
+   │ ods.location_event_errors  │    0 │
+   │ ods.device_by_click_errors │    0 │
    │ ods.geo_by_click_errors    │    0 │
    └────────────────────────────┴──────┘
 ```
 
-Прочитаем эту табличку по строчкам — в ней три вещи, которые стоит заметить.
+Прочитаем эту табличку — в ней три вещи, которые стоит заметить.
 
 **Все четыре `*_errors` — по нулям.** Значит, наш срез чистый: ни одна запись не дала ошибки
 разбора, столбец `parse_errors` у всех пустой. Это нормально — данные в демо аккуратные.

docs/course/lessons/03_ods_to_dds.md

@@ -105,6 +105,9 @@ DDS»** — счётчики строк по двум нашим сущност
    └────────────┴───────┴─────────────────────┴───────────────┴─────────────┘
 ```
 
+В колонке `check_date` стоит `today()` из кода витрины, так что у тебя там будет сегодняшняя
+дата — не пугайся, если она не совпадёт с примером.
+
 `orphan_events = 0` — ни одной сироты. Каждое из 50 событий нашло свой клик в `dds.click`. На
 чистом демо-срезе так и должно быть: данные аккуратные, ничего не потерялось. В секции 4 мы
 сироту устроим сами — и эта строка оживёт.

docs/course/lessons/05_monitoring.md

@@ -270,7 +270,7 @@ Grafana.
 Открой Grafana → **Airflow Overview** и найди панель **Scheduler Heartbeat Rate**.
 
 Потом открой **Alerting → Alert rules** и найди правило `Airflow Scheduler Down`. Перед
-экспериментом оно должно быть не в `Alerting`.
+экспериментом оно должно быть в состоянии `Normal` (не `Alerting`).
 
 Можно проверить и командой: