docs(63): правки по двум холодным ревью реализации

- Зачем:
  - линия дефектов нашла три неверных утверждения и мёртвый замер, линия
    уместности — три пересказа уже сказанного.
- Что:
  - «тип колонки не решает, какое число ляжет» сужено до правды: разбор
    отдаёт готовое число, а пояс приёмника решал бы судьбу строки.
  - замер до правки типов помечен как неповторяемый на нынешнем стенде.
  - правило о поясе сервера привязано к местам, где линза что-то решает:
    матвью приёма пояс не называет, и это не нарушение.
  - убраны: пересказ механики в ADR 0005, четыре строки учебного
    комментария, утверждение о порядке файлов и «секунды от начала эпохи»
    у миллисекундной метки.
- Проверка:
  - make lint, make typecheck, make test (408 тестов)
  - make clean && make up && make check-clickhouse — 9 из 9

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

sql/ddl/10-stg-tables.sql

@@ -41,7 +41,7 @@ SETTINGS
 -- виртуальные колонки его не несут, а после записи в Distributed он уже
 -- невосстановим.
 --
--- kafka_timestamp — Nullable(DateTime64(3)), и заполняется из виртуальной
+-- kafka_timestamp — Nullable(DateTime64(3, 'UTC')), и заполняется из виртуальной
 -- колонки _timestamp_ms, а не из _timestamp. Измерено на стенде 5 августа
 -- 2026 года: _timestamp — Nullable(DateTime), то есть секунды; _timestamp_ms —
 -- Nullable(DateTime64(3)). Взяты миллисекунды: у брокера метка миллисекундная,
@@ -49,12 +49,10 @@ SETTINGS
 -- округлять ему нечего. Обнуляемость обязательна: метку брокер заполняет не
 -- всегда, а необнуляемый тип дал бы либо падение приёма, либо тихий 1970 год.
 --
--- Пояс у обеих меток написан в типе — DateTime64(3, 'UTC'); в DDL стенда он
--- встречается здесь впервые. Само число от пояса не зависит, это секунды от
--- начала эпохи. Пояс — линза: по нему решают, какие часы покажут метку и в
--- какие сутки она попадёт, то есть чем окажется toDate(_load_ts) в ключе
--- партиции ниже. Не назови линзу — её выберет пояс сервера, умолчание, которого
--- в коде не видно. Правило целиком — docs/architecture/storage.md, «Часовые
+-- Пояс у обеих меток написан в типе. Хранимого числа он не меняет, а решает,
+-- в какие сутки метка попадёт, — то есть чем окажется toDate(_load_ts) в ключе
+-- партиции ниже. Не напиши его — пояс возьмётся у сервера, а это умолчание в
+-- коде не видно. Правило целиком — docs/architecture/storage.md, «Часовые
 -- пояса».
 --
 -- Нарезка и срок жизни — по _load_ts, то есть по реальному времени загрузки:

sql/ddl/30-ods-views.sql

@@ -55,7 +55,8 @@
 -- Третьим аргументом назван пояс — 'UTC'. Суффикс Z маска сверяет как букву и
 -- выбрасывает, зоны из строки не берёт вовсе, поэтому без имени функция читала
 -- бы показания часов по поясу сессии, а тот по умолчанию серверный. Тип
--- колонки этого не чинит: он про то, как число покажут, а не какое ляжет.
+-- колонки этого не чинит: разбор отдаёт готовое число, и колонка кладёт его
+-- как есть — пояс приёмника решал бы судьбу строки, а не числа.
 -- Правило и замер — docs/architecture/storage.md, «Часовые пояса».
 --
 -- EventDate в такой подпорке не нуждается: дата уезжает как «2026-06-01», и