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/specs/2026-08-01-generator.md

@@ -275,9 +275,11 @@
   «принимает ISO без плясок». Не принимает — на строке с суффиксом `Z` он
   отдаёт NULL, и при исполнении #43 это увело бы в брак все события до
   единого. Измерено на стенде 7 августа 2026 года; форма на проводе от этого
-  не меняется, меняется выражение разбора на стороне хранилища —
-  `parseDateTimeBestEffortOrNull` вместо `JSONExtract`
-  ([ADR 0005](../adr/0005-event-ingestion.md)).
+  не меняется, меняется выражение разбора на стороне хранилища — `parseDateTime`
+  по буквально названному формату вместо `JSONExtract`
+  ([ADR 0005](../adr/0005-event-ingestion.md)). То, что форма на проводе одна и
+  каноническая, здесь работает на хранилище: раз запись ровно одна, разбирать
+  её можно строго, не принимая заодно десяток чужих записей.
 
   Форму реализует сериализатор (#41), хранилище (#43) читает то, что он
   положил: порядок тикетов развёрнут 6 августа 2026 года, и отправитель идёт