feat(stg): DDL-бутстрап, топик hits и приём сырья обеими нодами

Зачем: стенду нужен воспроизводимый холодный старт, при котором схема
хранилища и топик появляются сами, а сырьё из Kafka доезжает в STG обеими
нодами кластера — без ручных шагов между `make clean` и рабочим приёмом.

Что:
- `sql/ddl/` — три файла, применяются по порядку имён: базы `stg` и `ods`,
  Kafka-чтец `hits_raw_kafka` формата RawBLOB, реплицируемая `hits_raw_rep`
  с окном TTL в трое суток, распределённая `hits_raw_dist` и матвью
  `hits_raw_mv`, переносящая сырьё вместе с метаданными доставки.
- `compose.yaml` — службы `kafka-init` (топик `hits` на две партиции, с
  ремонтом уже созданного однопартиционного) и `clickhouse-init` (применяет
  `/ddl/*.sql`); `hostname:` у обеих нод, чтобы `hostName()` отдавал имя узла,
  а не идентификатор контейнера; `airflow-init` зависит от `clickhouse-init` —
  без зависимого успешный одноразовый сервис считается упавшим для `--wait`.
- Доки: конвенции и раздел «Что проверено» в справочнике хранилища, указатели
  и границы обещаний в ADR 0005, снятые пункты в разделе 11 спеки.

Проверка: `make lint`, `make typecheck`, `make config-test`, `make smoke`
(25 проверок), `make smoke-guards` — зелёные. Приёмочный прогон с чистого
тома подтвердил все пять критериев #37: холодный старт и идемпотентный
повтор, две партиции у `hits`, метаданные доставки у доехавшего сообщения,
обе партиции на обеих потребляющих нодах в одном прогоне, некорректный JSON
лежит сырым и приём не встаёт.

Известная граница: RawBLOB молча теряет запись с пустым значением и
запись-надгробие; принято как свойство, замер и довод — в справочнике
хранилища.

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

docs/specs/2026-07-30-stand-v2-realism.md

@@ -579,18 +579,19 @@ smoke-проверки, а не «дашборд зелёный». Это мин
 
 ## 11. Проверить при исполнении
 
+Список убывает по мере постройки: проверенное уходит отсюда, а ответ с датой
+остаётся там, где на него опираются. Формат чтеца и форма виртуальной метки
+времени закрыты при исполнении #37 — см. [доку
+хранилища](../architecture/storage.md), раздел «Что проверено».
+
 - Поведение соединения двух Distributed-таблиц и `distributed_product_mode` —
   эмпирически на стенде (хвост #14).
 - Kafka Engine на двух нодах в одной consumer group: ребаланс партиций между
-  прогонами, отсутствие дублей при штатной работе.
+  прогонами, отсутствие дублей при штатной работе. Закрыто пока наполовину: что
+  обе ноды читают топик и обе партиции доезжают, показал #37; что дублей нет и
+  как раскладка меняется между прогонами — нет.
 - Точная форма `ORDER BY` ODS-таблиц (выражение `intHash32` в ключе
   ReplacingMergeTree).
-- `RawBLOB` в Kafka-движке даёт ровно одну строку на сообщение (ADR 0005).
-  Проверять первым, до написания DDL: если сообщения склеятся, переделывать
-  придётся решение, а не запрос. Запасной формат — `LineAsString`.
-- Тип виртуальной колонки `_timestamp` у Kafka-движка: обнуляемость и
-  разрядность (секунды против миллисекунд) — от этого зависит объявление
-  `kafka_timestamp` в таблице сырья.
 - Матвью с источником-`Distributed` срабатывает на вставку именно в эту
   распределённую таблицу, до раскладки по шардам: на этом стоит цепочка
   STG → ODS (ADR 0005). Проверено владельцем на рабочих проектах, в документации