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>

generator/src/clickstream_generator/schema.py

@@ -4,9 +4,9 @@
 1.1–1.2) и здесь не переоткрываются — модуль записывает их машинно-читаемо.
 Контракт принадлежит генератору и кормит трёх потребителей: сам генератор,
 его валидацию и «описание выгрузки» в доках (`schema_doc`). Хранилище
-строится по описанию, а не по модулю; границу будет сторожить contract-тест,
-сверяющий `system.columns` поднятого стенда с этим контрактом, — он придёт
-вместе с типизированным ODS (спека генератора, раздел 3).
+строится по описанию, а не по модулю; границу сторожит строгий приём на его
+стороне — сверка набора ключей сообщения с контрактным списком, и
+разошедшееся уходит в `ods.event_errors` (спека генератора, раздел 3).
 
 Что несёт описатель колонки:
 
@@ -16,7 +16,8 @@
   `system.columns`: параметры входят в имя типа целиком, без сокращений
   (`LowCardinality(String)`, `Array(Float64)`). Сверено 2026-08-01 —
   по документации ClickHouse через Context7 и запросом к узлу стенда
-  (26.3.17.56); от этой записи зависит будущий contract-тест.
+  (26.3.17.56). Запись важна потому, что по ней человек пишет DDL: тип,
+  сокращённый здесь, приедет в таблицу сокращённым же.
 - `numpy_dtype` — чем колонка представлена внутри генератора; у массивов это
   тип элемента. Строки живут в `object`-массивах: numpy-строки фиксированной
   длины стенду ничего не дают.