docs(testing): корректность процессов — в даги DQ, не в цели make

- Зачем:
  - находка «это стоило бы проверять регулярно» решалась заново в каждом
    тикете и каждый раз тянулась в make check-clickhouse. У неё есть
    назначенный дом: даги качества данных, которые придут со следующими
    уровнями хранилища.
- Что:
  - добавлен раздел «Корректность процессов живёт в дагах DQ, а не в целях
    make»: цели make отвечают «стенд собран», свойства данных — работа дага.
  - назван фильтр: про полноту дня, свежесть слоя, сходимость витрины с
    источником — это даг, а не цель.
  - названа учебная сторона: даг идёт по расписанию, пишет историю проверок
    и разбирается как обычная задача Airflow — так качество данных устроено
    в бою.
- Проверка:
  - make config-test

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

docs/architecture/testing.md

@@ -121,6 +121,21 @@ ClickHouse отвечает сразу.
 сломанный разбор (события уехали в брак — счёт разошёлся), ничего при этом не
 вкладывая.
 
+## Корректность процессов живёт в дагах DQ, а не в целях `make`
+
+Цели `make` отвечают на вопрос «стенд собран и работает». Вопрос «данные в нём
+правильные» — работа отдельных дагов качества данных: они приходят вместе со
+следующими уровнями хранилища и заберут многое из того, что просится проверкой
+сейчас. Поэтому находка «это стоило бы проверять регулярно» сначала проверяется
+вопросом, не туда ли ей: если она про свойства данных — про полноту дня, про
+свежесть слоя, про сходимость витрины с источником, — её дом даг, а не
+`check-clickhouse`.
+
+Разница видна и менти, и она содержательная. Цель `make` он зовёт руками,
+когда чинит стенд; даг DQ идёт по расписанию рядом с остальным конвейером,
+пишет историю проверок и разбирается как обычная задача Airflow — то есть учит
+тому, как качество данных устроено в бою.
+
 ## Устройство скриптов
 
 | Цель | Скрипт |