fix(monitoring): панели уточнены по ревью, приёмка снята под нагрузкой

- Зачем:
  - слияния в верхних строках показывали только журналы самого сервера, а
    предел в 15 строк рвал пару нод пополам: панели отвечали не на свой вопрос.
- Что:
  - «Слияния» стали столбиками по слоям: журналы сервера отделены, ряды ods и
    stg видны своими.
  - «Части» показывают все таблицы слоёв целиком, без предела и без обрезанных
    пар.
  - у «Запросов» убран «Поток запросов» — его пол составляли пробники
    состояния; у «Кто спрашивает» убрана лишняя колонка.
  - ряд «коробка» назван «отведено» — как в заголовке панели.
  - доводы дописаны в cluster.md и queries.md, отступления от ADR 0002
    записаны в сам ADR.
- Проверка:
  - make config-test; make smoke 21/21; make check-clickhouse 10/10.
  - все десять панелей отвечают через /api/ds/query в окнах на полчаса, час и
    шесть часов.

docs/adr/0002-monitoring-scope.md

@@ -127,6 +127,14 @@ ClickHouse, Kafka и Airflow, 17 — в дашборде генератора, 1
 keeper, и обе ноды читают её целиком — запрос вернул с каждой одни и те же 124
 записи. Обёртка там не добавила бы правды, а удвоила бы каждую строку, поэтому
 единственная панель «Кластера» без неё — эта. Keeper своих системных таблиц не
-имеет вовсе, и панель по нему приходит из Prometheus. Устройство обоих
-дашбордов — [cluster.md](../architecture/monitoring/cluster.md) и
+имеет вовсе, и панель по нему приходит из Prometheus.
+
+«Запросы» получили на две панели больше, чем сказано выше. Разбор запросов по
+посетителям продиктован [ADR 0007](0007-clickhouse-access.md): своя учётка
+Grafana заведена там ровно затем, чтобы её запросы были отличимы от
+человеческих.
+Отдельная панель ошибок понадобилась под здешний же сюжет про тяжёлый
+`GROUP BY`: отказ по памяти случается на шарде, и текст ошибки — единственное
+место, где написано, на каком. Устройство обоих дашбордов —
+[cluster.md](../architecture/monitoring/cluster.md) и
 [queries.md](../architecture/monitoring/queries.md).