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/architecture/storage.md

@@ -391,7 +391,7 @@ ODS. Второе: матвью приёма создаётся последне
 таймауту; `CREATE ... IF NOT EXISTS` на существующем объекте не бросает.
 
 **Проверено на стенде.** Опыты прогнаны на живом кластере: пять при исполнении
-#37 (четыре 5 августа 2026 года, пятый 6 августа) и четыре при исполнении #43
+#37 (четыре 5 августа 2026 года, пятый 6 августа) и пять при исполнении #43
 (7 августа). Все подтвердили то, что здесь написано.
 
 - Матвью с источником-`Distributed` срабатывает на вставку именно в эту
@@ -413,6 +413,15 @@ ODS. Второе: матвью приёма создаётся последне
   залитого дважды: у каждого события метка совпала с меткой одной из двух его
   доставок, а после `FINAL` — с меткой поздней. Случаев «метки нет среди
   доставок» ноль, то есть `now64()` в матвью разбора нет.
+- Пересозданная матвью пропускает ближайшие сообщения. Снятые и заново
+  созданные матвью разбора при живом чтеце: сообщение, отправленное сразу
+  после, легло в сырьё и не попало в ODS никуда — ни в событие, ни в ошибки;
+  то же сообщение через минуту разобралось штатно. Воспроизведено дважды
+  7 августа 2026 года. Это тот же зазор, о котором предупреждает нумерация
+  файлов DDL, только приходит он с другой стороны — не при первом создании, а
+  при замене матвью на работающем стенде. Практический вывод один: правишь
+  матвью — не верь ближайшей отправке, повтори её. Чем именно держится
+  задержка, не измерено; наблюдение записано как наблюдение.
 - Форма ключа `ods.event` принимается такой, как её задумала спека: выражение
   `intHash32(ClientID)` стоит в ключе сортировки `ReplacingMergeTree`, а
   `SAMPLE BY` — по тому же выражению. Вопрос стоял открытым в разделе 11