feat(smoke): смоук спрашивает Kafka снаружи — по объявленному адресу

- Зачем:
  - деление целей оставило дыру: про Airflow, Superset, Prometheus и Grafana
    смоук стучится с машины в отображённый порт, а про Kafka после переезда
    check_kafka_from_host знал только «контейнер здоров».
  - вердикт этот приходит из healthcheck в compose.yaml, а тот спрашивает
    брокер изнутри и по внутреннему слушателю: объявленный наружу адрес может
    вести не туда, и Kafka всё равно останется здоровой.
  - поломка популярная и показательная: клиент подключается, получает
    метаданные и молча виснет на адресе, которого с его стороны нет. Менти
    узнаёт, что у брокера два слушателя и зачем нужен advertised.listeners.
    Генератор будет писать в Kafka именно с машины.
- Что:
  - check_kafka_external_listener в make smoke: запрос списка топиков с машины
    через отображённый порт, ответ приходит только если объявленный адрес ведёт
    туда же. Комментарий у проверки объясняет, от чего она заведена.
  - ожидание ответа ограничено 15 секундами при замеренных 2,6 — впятеро
    больше, чем стоит зелёный прогон.
  - README и карта проверок: новая проверка названа, доводы записаны, цена
    смоука обновлена с 6 до 8 секунд.
- Проверка:
  - make config-test, make smoke (20 проверок, 8 с), make check-clickhouse,
    make check-services — зелёные.
  - краснеет на своей поломке: брокеру объявлен адрес kafka-nowhere:29092 при
    целом внутреннем слушателе — проверка состояния контейнера осталась
    зелёной, смоук покраснел именно на этой строке. После проверки Kafka
    возвращена в исходное состояние, посторонних контейнеров не осталось.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

README.md

@@ -70,11 +70,12 @@ make smoke
 Superset, создаёт администратора и импортирует подключение к `clickhouse-02`.
 
 `make smoke` за секунды спрашивает, собран ли стенд: зависимости машины,
-здоровье контейнеров, устройство keeper, три цели Prometheus, источник Grafana,
-компоненты Airflow и подготовленное подключение к `clickhouse-01`. В конце
-проверка спрашивает у Docker, не убивало ли ядро что-нибудь в долгоживущих
-контейнерах за нехватку памяти и не включалась ли политика перезапуска: убитый
-контейнер Docker поднимает сам, и проверка состояния об этом промолчит.
+здоровье контейнеров, устройство keeper, ответ Kafka с машины через отображённый
+порт, три цели Prometheus, источник Grafana, компоненты Airflow и подготовленное
+подключение к `clickhouse-01`. В конце проверка спрашивает у Docker, не убивало
+ли ядро что-нибудь в долгоживущих контейнерах за нехватку памяти и не включалась
+ли политика перезапуска: убитый контейнер Docker поднимает сам, и проверка
+состояния об этом промолчит.
 
 Одиннадцать проверок здоровья сразу после `make up --wait` повторяют то, чего
 Compose уже дождался: у каждой долгоживущей службы есть своя `healthcheck`.
@@ -85,13 +86,20 @@ Compose уже дождался: у каждой долгоживущей слу
 выглядит и без этого, поэтому смоук спрашивает у живого контейнера, дошли ли
 объявленные настройки до процесса.
 
-`make check-services` проверяет то, ради чего приходится ждать службу: Kafka
-через порт машины, ручной запуск пробников `test_clickhouse` и `test_kafka`,
-вход в Superset, его метаданные и подключение к `clickhouse-02`. Первый пробник
-создаёт таблицы на обеих нодах и читает через `Distributed` на ноде 2 строку из
-локальной таблицы ноды 1. Второй пишет в Kafka и читает свой маркер. Временный
-топик проверки с машины и запуски DAG удаляются; постоянный топик пробника
-сохраняется, а старые записи чистит Kafka.
+Kafka по той же причине спрашивают снаружи. Её `healthcheck` обращается к
+брокеру изнутри контейнера и по внутреннему слушателю, поэтому здоровой Kafka
+остаётся и тогда, когда объявленный наружу адрес ведёт не туда. Клиент с машины
+в этом случае подключается, получает метаданные и молча виснет на адресе,
+которого с его стороны не существует. Смоук идёт тем же путём, что и будущий
+генератор: стучится в отображённый порт и просит список топиков.
+
+`make check-services` проверяет то, ради чего приходится ждать службу: работу с
+топиком Kafka с машины — создан, найден, удалён, — ручной запуск пробников
+`test_clickhouse` и `test_kafka`, вход в Superset, его метаданные и подключение
+к `clickhouse-02`. Первый пробник создаёт таблицы на обеих нодах и читает через
+`Distributed` на ноде 2 строку из локальной таблицы ноды 1. Второй пишет в Kafka
+и читает свой маркер. Временный топик проверки с машины и запуски DAG удаляются;
+постоянный топик пробника сохраняется, а старые записи чистит Kafka.
 
 `make check-clickhouse` запускает отдельную глубокую проверку ClickHouse:
 описание кластера, макросы, связь с keeper, `ReplicatedMergeTree`,