docs(monitoring): приёмка дашборда переехала к дашборду

- Зачем:
  - в общем разделе «Что проверено» лежали два разных прогона, пола и
    дашборда; следующие дашборды копили бы там осадок.
- Что:
  - запись о приёмке дашборда «Данные» перенесена в data.md, в README.md
    осталась приёмка самой зоны.
- Проверка:
  - make config-test.

docs/architecture/monitoring/README.md

@@ -91,26 +91,3 @@ ClickHouse через MCP Context7; разбор — в
 - Prometheus видит ровно четыре цели, все со значением `up = 1`; запрос
   `kafka_consumergroup_lag` вернул ряды по группам `clickstream_*`.
 - `make smoke` 21/21, `make check-clickhouse` 10/10, `make check-services` 7/7.
-
-Дашборд «Данные» проверен на живом стенде в тот же день, `world_live` снят с
-паузы.
-
-- Дашборд поднимается из каталога сам: файл положен, панели появились без
-  ручного импорта. Сохранение и удаление через API отвергнуты («Cannot save
-  provisioned dashboard», «provisioned dashboard cannot be deleted»).
-- Все шесть панелей отвечают через `/api/ds/query` — и в окне часа по
-  умолчанию, и в окне на шесть часов, которое начинается раньше, чем поднялся
-  экспортёр. Пустых нет ни при идущем потоке, ни при остановленном.
-- Брак: подсунутое в топик `hits` негодное сообщение легло в
-  `ods.event_errors` с классом `keyset_mismatch`; панель показала единицу и
-  долю 0,039 % в десятиминутном окне. Строка убрана мутациями из
-  `stg.hits_raw_rep` и `ods.event_errors_rep`, обе таблицы вернулись к нулю.
-- Сходимость: на живом потоке за двадцать пять минут медиана расхождения между
-  рядами 3 %, худший столбец 11 % — на переломе потока, как и описано в
-  [data.md](data.md). Отказы тоже по замеру: `increase` расходился сильнее, а
-  накопленный итог пропадал целиком, стоило окну начаться раньше экспортёра.
-- Свежесть реагирует на остановленный поток и возвращается. Через пять минут
-  после конца модельного дня панель показала 305 с у событий и 288 с у
-  заказов; стоило пустить следующий день, события вернулись к секунде.
-  Свежесть заказов при этом растёт до конца дня и садится, когда доедет его
-  слепок, — так и устроен второй источник.

docs/architecture/monitoring/data.md

@@ -92,3 +92,28 @@ Kafka идёт чуть выше. Читается устойчивый разр
 другой — не «сходится ли поток», а «доехала ли выгрузка и вовремя ли». На него
 отвечает своя панель, и модельный день она берёт из самого сообщения: в сырьё
 он приезжает полем `snapshot_date`.
+
+## Что проверено
+
+Дашборд проверен на живом стенде 21 августа 2026 года, `world_live` снят с
+паузы.
+
+- Дашборд поднимается из каталога сам: файл положен, панели появились без
+  ручного импорта. Сохранение и удаление через API отвергнуты («Cannot save
+  provisioned dashboard», «provisioned dashboard cannot be deleted»).
+- Все шесть панелей отвечают через `/api/ds/query` — и в окне часа по
+  умолчанию, и в окне на шесть часов, которое начинается раньше, чем поднялся
+  экспортёр. Пустых нет ни при идущем потоке, ни при остановленном.
+- Брак: подсунутое в топик `hits` негодное сообщение легло в
+  `ods.event_errors` с классом `keyset_mismatch`; панель показала единицу и
+  долю 0,039 % в десятиминутном окне. Строка убрана мутациями из
+  `stg.hits_raw_rep` и `ods.event_errors_rep`, обе таблицы вернулись к нулю.
+- Сходимость: на живом потоке за двадцать пять минут медиана расхождения между
+  рядами 3 %, худший столбец 11 % — на переломе потока, как и описано выше.
+  Отказы тоже по замеру: `increase` расходился сильнее, а накопленный итог
+  пропадал целиком, стоило окну начаться раньше экспортёра.
+- Свежесть реагирует на остановленный поток и возвращается. Через пять минут
+  после конца модельного дня панель показала 305 с у событий и 288 с у
+  заказов; стоило пустить следующий день, события вернулись к секунде.
+  Свежесть заказов при этом растёт до конца дня и садится, когда доедет его
+  слепок, — так и устроен второй источник.