fix(ods): метка времени разбирается по названному формату, а не best-effort

Зачем: parseDateTimeBestEffort на непонятной строке не краснеет, а достраивает
недостающее — обрезанное «20:00:21» становится первым января текущего года.
Такое сообщение проходило строгий приём с тихо неверным временем, то есть с
той самой порчей, ради которой класс key_field_unparsed и заведён.

Что:
- В обеих матвью разбор метки идёт parseDateTimeOrNull по формату
  '%Y-%m-%dT%H:%i:%SZ'. Форма на проводе одна и каноническая, поэтому широта
  best-effort не нужна вовсе, а платится за неё отключённой проверкой.
- Замеры в ADR 0005: три записи, которые best-effort достраивает; проверка,
  что настройка cast_string_to_date_time_mode не спасает JSONExtract; сверка
  на настоящих данных — по всем 101 252 строкам сырья модельного дня точный
  формат разобрал метку у каждой и ни на одной не разошёлся с best-effort.
- Записано наблюдение стенда: пересозданная на живом чтеце матвью пропускает
  ближайшее сообщение мимо ODS, через минуту то же сообщение разбирается.
  Воспроизведено дважды; на нём я сам споткнулся при проверке этой правки.

Проверка: опыт строгого приёма прогнан заново — три сообщения дали событие и
два key_field_unparsed, включая обрезанную метку, которая раньше проходила
годной. DDL применяется на живом кластере.

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

docs/adr/0005-event-ingestion.md

@@ -211,14 +211,31 @@ ClickHouse 26.3.17.56. Все четыре ответили так, как жд
 строке 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`
-без оговорок.
+(«принимает ISO без плясок») — обещание было ошибочным и исправлено тем же PR.
+Настройка `cast_string_to_date_time_mode = 'best_effort'` дела не меняет:
+с ней суффикс берёт `CAST`, а `JSONExtract` по-прежнему отдаёт NULL — то есть
+внутренний разбор `JSONExtract` её не слушает. `EventDate` уезжает как
+`2026-06-01` и разбирается `JSONExtract` без оговорок.
+
+Разбор метки времени идёт
+`parseDateTimeOrNull(JSONExtractString(raw, 'UTCEventTime'), '%Y-%m-%dT%H:%i:%SZ')`
+— по буквально названному формату, а не через `parseDateTimeBestEffort`.
+Обе функции ISO-8601 понимают и обе в варианте `*OrNull` отдают NULL вместо
+исключения, то есть годятся в предикат. Выбран точный формат потому, что
+широта здесь работает против строгого приёма: `parseDateTimeBestEffort` на
+непонятной строке не краснеет, а достраивает недостающее. Измерено 7 августа
+2026 года — обрезанное `20:00:21` он превращает в `2026-01-01 20:00:21`,
+подставив текущий год и первое января; голая дата `2026-05-31` становится
+полуночью; строка цифр читается числом эпохи. Такое сообщение прошло бы
+строгий приём с тихо неверным временем — ровно с той порчей, ради которой
+класс `key_field_unparsed` и заведён. Разбор по названному формату отдаёт на
+всех трёх NULL. Источник у топика один и шлёт одну запись, так что широта не
+нужна вовсе, а платится за неё отключённой проверкой.
+
+Цена выбора измерена на настоящих данных: по всем 101 252 строкам сырья
+модельного дня (день залит дважды) точный формат разобрал метку у каждой, и
+ни на одной не разошёлся с `parseDateTimeBestEffort`. Различаются они только
+на порче.
 
 Оговорка к обнуляемому разбору даты, измеренная там же: `Nullable(Date)`
 даёт NULL на строке, которая датой не является вовсе («мусор»), и на числе,