docs(generator): зафиксирован контракт модельного времени

- Зачем:
  - нужно закрепить принятое человеком HITL-решение до кодовых задач 02-06.
- Что:
  - добавлен рабочий контракт настроек, хода часов, state, манифеста и ClickHouse-проверки.
  - выбран один живой ход часов через фиксированный модельный шаг без отдельной матрицы драйверов.
  - уточнена граница стартовой истории как [T0, T_end) и закрыт чек-лист issue 01.
- Проверка:
  - git diff --cached --check.

.scratch/generator-model-time-startup-history/PRD.md

@@ -35,12 +35,16 @@ Status: Draft
 
 ## Сквозные инварианты
 
+- Рабочий контракт реализации живёт в
+  `docs/specs/2026-06-14-generator-model-time-and-startup-history.md`, раздел
+  «Рабочий контракт реализации». Задачи 02–06 берут имена настроек, формат
+  манифеста, границу `T_end` и правила проверки оттуда.
 - `event_timestamp` — модельное время, а не настенные часы компьютера.
 - Операционные метки сервиса, история пачек, метрики здоровья и длительность
   тика остаются настенным временем, если отдельная задача не докажет обратное.
-- Контракт задачи 1 должен разделить, где повторяемость точная, а где
-  статистическая: промотка прошлого должна быть точной, живой режим зависит от
-  выбранного драйвера часов.
+- Живой ход часов идёт фиксированным модельным шагом
+  `GEN_TICK_SECONDS * GEN_MODEL_TIME_SPEED`; промотка прошлого тоже повторяется
+  точно при тех же настройках и чистом состоянии.
 - При ×K модельное время и событийный бюджет идут по модельной длительности
   тика, а не по реальной длительности сна процесса.
 - Часовой пояс модельных часов явно задан в контракте; дневной коэффициент
@@ -49,7 +53,8 @@ Status: Draft
   настенного времени, а не простым `datetime.now()`.
 - Стартовая история — это события плюс слепок состояния плюс манифест, чтобы не
   смешать данные от разных `GEN_SEED`, `T0` и `T_end`.
-- На стыке `[T0, T_end]` и живого продолжения не должно быть дублей и дыр.
+- Стартовая история покрывает `[T0, T_end)`, живое продолжение начинается из
+  слепка на `T_end`; на стыке не должно быть дублей и дыр.
 - Повторная проверка на чистом стенде должна быть воспроизводимой: либо команда
   явно чистит ClickHouse, Kafka-топики данных и состояние генератора, либо
   процесс идемпотентен.