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/adr/0005-event-ingestion.md

@@ -125,15 +125,20 @@ STG сырьё исключительно от брака: слой сырых
 присутствие, и потому сужен до пяти колонок.
 
 Цена решения. Контракт получает ещё два места: типы сорока семи колонок в
-выражениях матвью и список тех же имён для сверки ключей. Раздел 1.4 спеки
-предупреждает, что, повторяясь примерно в семи местах, они расходятся молча, а
-contract-тест из #43 сюда не дотягивается — он сравнивает `system.columns`
-целевой таблицы со схемой генератора и о выражениях матвью ничего не знает.
-Смягчение работает не везде: опечатка в имени скалярного поля уводит строки в
-таблицу ошибок пачкой и видна сразу, а опечатка в имени массива даёт пустой
-массив тихо — сверка ключей проверяет ключи сообщения, а не выражения матвью.
-Эти двенадцать колонок сторожит smoke: известное событие с товарами обязано
-доезжать с непустыми массивами.
+выражениях матвью и список тех же имён для сверки ключей — а список этот
+повторён дважды, по разу на матвью. Раздел 1.4 спеки предупреждает, что,
+повторяясь примерно в семи местах, они расходятся молча.
+
+И сверка ключей эту цену покрывает не всю: она смотрит на ключи сообщения, а
+не на выражения матвью. Опечатка в имени внутри `JSONExtract` даёт умолчание
+типа — ноль, пустую строку, пустой массив, — и молчит она у сорока двух
+обычных колонок ровно так же, как у двенадцати массивов. Громко ломаются
+только пять опорных: у них разбор `Nullable` стоит в предикате, и опечатка
+уводит в таблицу ошибок все строки до единой. Остальные сорок две сторожит
+сверка разобранного события против сырого текста — разовый опыт при
+исполнении #43, а не постоянная проверка; сила его в том, что выражения
+сверки собираются из контракта, а выражения матвью написаны руками по
+описанию выгрузки, и одна опечатка в двух местах не повторяется.
 
 Второе — разбор функциями дороже разбора форматом. На объёмах стенда это
 несущественно; если станет заметно, сорок семь вызовов сворачиваются в один
@@ -177,15 +182,42 @@ contract-тест из #43 сюда не дотягивается — он ср
 Тогда же нашлась и граница обещания — запись с пустым значением и
 запись-надгробие не дают строки вовсе; из-за неё в «Решении» и в «Почему»
 приписано слово «непустое». Замер целиком — в [доке
-хранилища](../architecture/storage.md), раздел «Что проверено». Остальные три
-по-прежнему ждут живого стенда; это однострочные `SELECT`, их довольно прогнать
-заодно:
+хранилища](../architecture/storage.md), раздел «Что проверено».
 
-- форма именованного кортежа в `JSONExtract` с `Nullable`-членами — нужна для
-  свёртки сорока семи вызовов в один, если разбор окажется дорогим;
-- `isValidJSON('123')` возвращает единицу, а `JSONExtractKeys` от скаляра —
-  пустой массив. На обоих стоят классы брака и их приоритет, а документация
-  поведение на не-объекте не описывает: два `SELECT` закрывают вопрос;
-- `JSONAsString` действительно падает на некорректном JSON, а не пропускает
-  строку. На этом стоит отказ от него в пользу `RawBLOB`; документация про
-  ошибочный ввод молчит.
+Остальные четыре закрыты при исполнении #43, на стенде 7 августа 2026 года,
+ClickHouse 26.3.17.56. Все четыре ответили так, как ждала постановка:
+
+- `isValidJSON('123')` возвращает единицу — скаляр законный JSON, и первый
+  класс брака поэтому проверяет именно объект, а не валидность;
+- `JSONExtractKeys('123')` возвращает пустой массив, и он же приходит от
+  вовсе не-JSON. Значит скаляр проваливает и сверку ключей — отсюда
+  обязательный порядок классов;
+- `JSONAsString` на некорректном вводе падает, а не пропускает строку: код 117
+  `INCORRECT_DATA`, «JSON object must begin with '{'». Падает и на скаляре
+  `123`. На этом стоит отказ от него в пользу `RawBLOB`;
+- форма именованного кортежа с `Nullable`-членами работает и годится в
+  запасной вариант: `JSONExtract(raw, 'Tuple(WatchID Nullable(UInt64), …)')`
+  даёт NULL в тех членах, что не разобрались, обращение по имени члена
+  доступно, а на не-объекте кортеж выходит целиком из NULL и исключения нет.
+
+Тем же заходом нашлось то, о чём никто не спрашивал, и оно оказалось
+блокирующим. **`JSONExtract` с типом `DateTime` не разбирает ISO-8601 с
+суффиксом зоны.** На проводе `UTCEventTime` уезжает как
+`2026-06-01T12:34:56Z` (спека генератора, раздел 4), а
+`JSONExtract(raw, 'UTCEventTime', 'Nullable(DateTime)')` отдаёт на такой
+строке NULL — то есть все события до единого уходили бы в брак с классом
+`key_field_unparsed`. Ни `DateTime64`, ни `DateTime('UTC')` суффикс тоже не
+берут; без `Z` та же строка разбирается. Спека генератора обещала обратное
+(«принимает ISO без плясок») — обещание было ошибочным и исправлено тем же
+PR. Разбор метки времени поэтому идёт
+`parseDateTimeBestEffortOrNull(JSONExtractString(raw, 'UTCEventTime'))`:
+документация ClickHouse прямо относит ISO-8601 к форматам
+`parseDateTimeBestEffort` (сверено через Context7 7 августа 2026 года), а
+вариант `*OrNull` возвращает NULL вместо исключения и потому годится в
+предикат. `EventDate` уезжает как `2026-06-01` и разбирается `JSONExtract`
+без оговорок.
+
+Оговорка к обнуляемому разбору даты, измеренная там же: `Nullable(Date)`
+даёт NULL на строке, которая датой не является вовсе («мусор»), и на числе,
+но невозможную дату `2026-13-99` молча приводит к `1970-01-01`. То есть
+класс `key_field_unparsed` ловит порчу типа, а не порчу значения внутри типа.