docs(labs): ТЗ необязательной лабы «свой дашборд в Superset»

Зачем: владеть хотя бы одним BI-инструментом на базовом уровне — полезный
навык дата-инженера, но стенд в первую очередь про ClickHouse, поэтому
лаба необязательная. Обещание «отдельная домашка после этапа 8» в доке DM
висело без адреса.

Что: ТЗ docs/labs/superset-dashboard.md — пять датасетов поверх публичных
представлений заданий 1-5, свой дашборд отдельно от стендового, проверка
глазами без homework_check; шестая строка и разведение «пяти заданий по
витринам» в docs/labs/README.md; абзац о сроке жизни объектов менти в
docs/architecture/superset.md; ссылка на лабу из доки DM; правило слага в
AGENTS.md расширено до «предмет задания».

Проверка: кода и DDL нет; слепое ревью текста (9 находок закрыто, 2
дополнительные с перепроверки) и финальная вычитка.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

docs/labs/README.md

@@ -1,9 +1,13 @@
-# Учебные задания: витрины слоя DM
+# Учебные задания: витрины слоя DM и дашборд в Superset
 
-Пять домашек. Стенд привозит слой DM наполовину: витрины трех сюжетов
-дашборда и контроль качества построены, остальные витрины строит менти.
-Каждое задание — самостоятельное ТЗ: что за витрина, какое у нее зерно,
-из чего она собирается и как проверить, что собралась верно.
+Пять домашних заданий — про витрины слоя DM. Стенд привозит слой
+наполовину: витрины трех сюжетов дашборда и контроль качества построены,
+остальные витрины строит менти. Каждое из них — самостоятельное ТЗ: что за
+витрина, какое у нее зерно, из чего она собирается и как проверить, что
+собралась верно.
+
+Шестое задание — необязательная лаба в Superset. В ней менти собирает свой
+дашборд поверх пяти витрин.
 
 Общее устройство слоя — [дока DM](../architecture/dm.md). Она отвечает на
 вопросы «почему так», задание отвечает на вопрос «что сделать».
@@ -13,18 +17,19 @@
 Задания идут по нарастанию: каждое следующее опирается на то, что уже
 усвоено.
 
-| № | Витрина | Чему учит |
+| № | Результат | Чему учит |
 |---|---|---|
 | 1 | [`events_enriched_v`](events-enriched.md) | слой — это контракт, а не копия данных |
 | 2 | [`top_pages_daily`](top-pages-daily.md) | зерно сменилось — витрина материализуется и встает в конвейер |
 | 3 | [`session_overview`](session-overview.md) | зерно решает, на какие вопросы витрина уже не ответит |
 | 4 | [`dq_errors_daily`](dq-errors-daily.md) | у брака свой день и свой срок жизни |
 | 5 | [`utm_effectiveness`](utm-effectiveness.md) | `declared_` в имени — предупреждение, а не украшение |
+| 6 | [Свой дашборд в Superset](superset-dashboard.md) — необязательная лаба | свои объекты BI живут отдельно от стендовых |
 
 ## Общие правила
 
-Они одни на все пять заданий, поэтому записаны здесь, а не повторяются в
-каждом ТЗ.
+Они одни для пяти заданий по витринам, поэтому записаны здесь, а не
+повторяются в каждом ТЗ.
 
 **Читать — через `_v`.** Публичный договор сущности DDS — представление с
 суффиксом `_v`: `dds.event_v`, `dds.session_v`. Витрина называет только
@@ -74,18 +79,18 @@ DDS, и задания остаются независимыми. Исключе
 собрано верно. В сводку качества конвейера `dm.dq_summary` он не пишет:
 это инструмент лабы, а не история качества стенда.
 
-Проверка у всех заданий устроена одинаково и золотых констант не содержит:
-рядом с витриной независимым запросом собирается тот же ответ — прямо из
-источника витрины, минуя ее саму. У четырех заданий источник эталона тот
-же, что у витрины, `dds.session_v` или `dds.event_v`; у задания 4 это
-таблицы брака ODS, потому что в DDS у брака представительства нет. Обе
-стороны соединяются по деловому ключу через `FULL OUTER JOIN`, и считается
-число строк, где стороны разошлись или одной стороны нет. Ноль — зеленый.
+Проверка пяти заданий по витринам устроена одинаково и золотых констант не
+содержит: рядом с витриной независимым запросом собирается тот же ответ —
+прямо из источника витрины, минуя ее саму. У четырех заданий источник эталона
+тот же, что у витрины, `dds.session_v` или `dds.event_v`; у задания 4 это
+таблицы брака ODS, потому что в DDS у брака представительства нет. Обе стороны
+соединяются по деловому ключу через `FULL OUTER JOIN`, и считается число строк,
+где стороны разошлись или одной стороны нет. Ноль — зеленый.
 Полное соединение здесь обязательно: при обычном пропавший день или
 пропавший ключ просто не попал бы в результат и остался бы незамечен.
 
-Раздел «Как проверить себя» каждого ТЗ называет деловой ключ и сравниваемые
-величины. Тот же прием в стендовом исполнении — [даг
+Раздел «Как проверить себя» каждого ТЗ по витрине называет деловой ключ и
+сравниваемые величины. Тот же прием в стендовом исполнении — [даг
 `dq_check`](../../dags/dq_check.py) и запросы в [`sql/dq/`](../../sql/dq).
 
 **Предупреждение.** Запросы самой проверки лежат в `sql/dq/` открыто, и