feat(ods): типизированное событие, строгий приём и таблица ошибок

Зачем: цепочка Kafka → STG → ODS достраивается последним этажом. Сырьё уже
доезжает (#37), настоящие события в топике есть (#41), а типизированного слоя
не было — событие негде было прочитать колонками, а брак негде увидеть.

Что:
- sql/ddl/20-ods-tables.sql — ods.event_rep/_dist на ReplacingMergeTree с
  версией _load_ts, партиция по EventDate, ключ по разделу 1.3 спеки,
  шардирование cityHash64(ClientID); ods.event_errors_rep/_dist с классом
  брака, своими ключами и сроком жизни в месяц.
- sql/ddl/30-ods-views.sql — две матвью над stg.hits_raw_dist. Годность
  считает предикат из трёх частей, вторая матвью берёт его дословное
  отрицание, класс брака пишется первым совпавшим из трёх.
- Метку времени разбирает parseDateTimeBestEffortOrNull, а не JSONExtract:
  ISO-8601 с суффиксом Z JSONExtract не берёт вовсе. Спека генератора
  обещала обратное — обещание поправлено, форма на проводе не менялась.
- Сверка объявлений (contract-тест) снята из документов и из докстрингов
  schema.py: сверх строгого приёма она ловила только смену типа.
- Документация приведена в соответствие: ADR 0005, дока хранилища и обе
  спеки; группа «сказано по памяти» в доке хранилища опустела.

Проверка: make up && make check-clickhouse (8 проверок, 7,5 с); make lint,
make typecheck, make test (406), make docs без диффа. Разовые опыты при
исполнении — в теле PR.

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

docs/architecture/storage.md

@@ -6,10 +6,11 @@
 раздел «Что проверено» — чему в этом тексте верить и на каком основании.
 
 **Что здесь описано и чего ещё нет.** Собран этап 1: кластер из двух шардов,
-keeper, Kafka, каркас сервисов. Этап 2 идёт: в `sql/ddl/` уже лежат базы слоёв
-и объекты STG — чтец топика `hits`, таблицы сырья и матвью приёма. Объектов ODS
-в репозитории пока нет. Дальше по тексту устройство описано так, как оно
-проектируется; построенное от заложенного отличает карта таблиц в конце.
+keeper, Kafka, каркас сервисов. Этап 2 идёт: в `sql/ddl/` лежит вся цепочка
+`Kafka → STG → ODS` — чтец топика `hits`, таблицы сырья, типизированное
+событие с таблицей ошибок и три матвью. Дальше по тексту устройство описано
+так, как оно проектируется; построенное от заложенного отличает карта таблиц в
+конце.
 
 Зона ответственности у документа одна — хранилище. Генератор описан отдельно:
 его замысел — в [спеке генератора](../specs/2026-08-01-generator.md), формат
@@ -229,9 +230,12 @@ NULL, — иначе трёхзначная логика даст строку,
 разъедется само: сырьё истечёт раньше, а перезаливка модельного дня задвоит его,
 тогда как в ODS тот же повтор схлопнется. Правило, красное в норме, учит не
 смотреть на оповещения
-([ADR 0002](../adr/0002-monitoring-scope.md)). Равенство проверяется разово в
-smoke на управляемой пачке: отправили N сообщений — получили N строк сырья и N в
-сумме событий и ошибок. Счёт по ODS идёт через `FINAL`: голый `count()` по
+([ADR 0002](../adr/0002-monitoring-scope.md)). Равенство проверено разовым
+опытом при исполнении #43, на управляемой пачке: отправили N сообщений —
+получили N строк сырья и N в сумме событий и ошибок. Постоянной целью такой
+опыт не становится, и почему — в [карте
+проверок](testing.md), раздел «Интеграционная проверка постоянной целью не
+становится». Счёт по ODS идёт через `FINAL`: голый `count()` по
 `ReplacingMergeTree` зависит от того, сколько мержей успело пройти, и спека это
 прямо запрещает (раздел 6).
 
@@ -345,8 +349,7 @@ ODS. Второе: матвью приёма создаётся последне
 
 ## Карта таблиц
 
-Ниже — то, что закладывает этап 2. DDL слоя STG уже лежит в `sql/ddl/`;
-объектов ODS в репозитории пока нет.
+Ниже — то, что закладывает этап 2; всё перечисленное лежит в `sql/ddl/`.
 
 | Слой | Объект | Что это |
 |---|---|---|
@@ -382,9 +385,24 @@ ODS. Второе: матвью приёма создаётся последне
 завязан на движок базы `Atomic`. `ON CLUSTER` ждёт все хосты и бросает по
 таймауту; `CREATE ... IF NOT EXISTS` на существующем объекте не бросает.
 
-**Проверено на стенде.** Опыты прогнаны на живом кластере при исполнении #37:
-четыре — 5 августа 2026 года, пятый — 6 августа. Все подтвердили то, что здесь
-написано.
+**Проверено на стенде.** Опыты прогнаны на живом кластере: пять при исполнении
+#37 (четыре 5 августа 2026 года, пятый 6 августа) и два при исполнении #43
+(7 августа). Все подтвердили то, что здесь написано.
+
+- Матвью с источником-`Distributed` срабатывает на вставку именно в эту
+  распределённую таблицу, до раскладки по шардам. Обе матвью разбора стоят над
+  `stg.hits_raw_dist`, а пишет в неё матвью приёма — и события доезжают до
+  `ods.event`; значит блок она видит. В документации ClickHouse случая нет
+  вовсе, до 7 августа утверждение держалось на опыте владельца.
+- Упавшая матвью роняет вставку и останавливает потребление до починки.
+  Проверено сносом цели — распределённой `ods.event_dist` — при живом чтеце: за
+  двадцать секунд (сброс блока идёт за 7,5) в сырьё не приехало ничего, а
+  офсет группы застыл с отставанием в одно сообщение. Цель вернули — сообщение
+  доехало само, без повторной отправки, отставание ушло в ноль, событие
+  разобралось. Сносить надо именно распределённую таблицу: вставка в
+  `Distributed` кладёт блок в спул и сразу возвращает управление, так что на
+  сносе локальной ошибка всплыла бы фоном и утверждение показалось бы
+  опровергнутым.
 
 - `RawBLOB` даёт ровно одну строку на каждое непустое сообщение. Три сообщения
   с ключами, поставленные в очередь до одного сброса продюсера, стали тремя
@@ -433,12 +451,5 @@ Kafka с пустым значением (ноль байт) и запись-н
 таблице. Это вычитано, а не измерено. На устройство приёма оговорка не влияет:
 служебные колонки мы заполняем выражением при любом ответе.
 
-**Сказано по памяти, проверки пока нет.** Осталось два утверждения, и оба ждут
-одного и того же — матвью разбора, а она приходит с #43.
-
-- Матвью с источником-`Distributed` срабатывает на вставку именно в эту
-  распределённую таблицу, до раскладки по шардам. В документации случая нет
-  вовсе, утверждение держится на опыте владельца.
-- Упавшая матвью роняет вставку и останавливает потребление до починки. На этой
-  фразе стоит правило «грязные записи не валят пайплайн», а сама она стоит пока
-  на одном рассуждении.
+**Сказано по памяти, проверки нет.** Группа пуста: оба утверждения, ждавшие
+матвью разбора, закрыты опытами при исполнении #43 и переехали выше.

docs/architecture/testing.md

@@ -22,10 +22,10 @@
 макросов `shard`: обе ноды здоровы и порты отвечают. `make check-clickhouse` не
 заметит потерянного подключения Superset: он про ClickHouse и только.
 
-Отсюда правило для новой проверки: **спроси, кого она спрашивает.** Договор со
-схемой событий — вопрос к ClickHouse, значит дом ему в `check-clickhouse`, даже
-если по цене он подошёл бы смоуку. Счётчики против манифеста — тоже вопрос к
-ClickHouse: строки в `ods.event` считает сам сервер и отвечает сразу.
+Отсюда правило для новой проверки: **спроси, кого она спрашивает.** Счётчики
+против манифеста — вопрос к ClickHouse: строки в `ods.event` считает сам
+сервер и отвечает сразу, значит дом им в `check-clickhouse`, даже если по цене
+они подошли бы смоуку.
 
 ## Карта целей