fix(monitoring): доводы приведены к замерам, пары нод больше не расходятся

- Зачем:
  - второй круг ревью нашёл, что текст спорит с собственной приёмкой: окно
    держалось доводом «слияния за минуту-две», а замер даёт двадцать секунд;
    довод панели ошибок опирался на отказ по памяти, которого ADR 0004 на этом
    стенде не обещает.
- Что:
  - «Части» сортируются по таблице: сортировка по числу частей разводила две
    ноды одной таблицы, как только между ними вставала чужая.
  - у «Слияний» столбик шириной в минуту, иначе редкие события выходили
    волосяной линией; из заголовка убран «слой» — фильтр отсекает журналы
    сервера, а не выбирает слои.
  - в cluster.md исправлены довод за окно, ложное «времени в system.parts нет»,
    счёт панелей без нод (их две, не одна) и разрешение, в котором снят замер
    процессора.
  - панель ошибок и её запись в ADR 0002 переписаны под проверенное: отказ на
    шарде воспроизведён принудительным пределом памяти.
  - из queries.md убран абзац про SELECT 1 — он объяснял пол удалённой панели.
- Проверка:
  - make config-test; make smoke 21/21; make check-clickhouse 10/10.
  - все десять панелей отвечают через /api/ds/query в окнах на полчаса, час и
    шесть часов; шаг столбика слияний проверен отдельным запросом.

docs/architecture/monitoring/queries.md

@@ -27,10 +27,6 @@ Grafana ходит в ClickHouse обычным пользователем, и
 остальное. Спрячь мы свои запросы фильтром — цена ушла бы с глаз, а панель «Кто
 спрашивает» недосчиталась бы самого частого посетителя.
 
-Там же, в «Кто спрашивает», стоит `default` с сотнями запросов и одной
-прочитанной строкой на каждый: это `SELECT 1` от проверки состояния
-контейнера, она ходит к каждой ноде раз в несколько секунд.
-
 Различать посетителей дашборд умеет потому, что у Grafana своя учётка со своей
 ролью ([ADR 0007](../../adr/0007-clickhouse-access.md)). Ходи она под
 аналитиком, панель «Кто спрашивает» показывала бы одну строку на всех.
@@ -46,9 +42,11 @@ Grafana ходит в ClickHouse обычным пользователем, и
 считают только запросы инициатора: иначе один запрос человека выглядел бы
 тремя, а прочитанные строки сложились бы дважды.
 
-Панель ошибок, наоборот, куски шардов показывает. Отказ по памяти случается
-там, где считали, — на шарде; инициатор в своей строке передаст только текст
-ошибки, а нода, на которой всё случилось, останется неназванной.
+Панель ошибок, наоборот, куски шардов показывает: отказ случается там, где
+считали, и строка шарда — единственное место, где эта нода названа. В замере с
+принудительным пределом памяти `clickhouse-01` записал свой отказ, а
+`clickhouse-02` — свой, и вторая строка видна только без фильтра по
+инициатору.
 
 ## Пустой пользователь
 
@@ -69,6 +67,10 @@ Grafana ходит в ClickHouse обычным пользователем, и
 - Ошибки видны и различаются по природе: отказ по правам (`bi` без `SELECT` на
   `ods`) и ошибка в тексте запроса (несуществующая колонка) легли в панель
   разными строками, каждая с полным текстом.
+- Строка шарда в панели ошибок настоящая. Принудительный предел памяти на
+  распределённом `GROUP BY` дал две записи: `clickhouse-01` с
+  `is_initial_query = 1` и `clickhouse-02` с нулём. Вторая пропала бы, стой на
+  панели тот же фильтр, что на соседних.
 - Панель «Кто спрашивает» разделила шесть учёток — `grafana`, `analyst`, `etl`,
   `dict`, `bi`, `default` — и фоновую работу сервера. Больше всех прочитала
   `grafana`: 11,5 млн строк за час, своими же панелями.