docs(generator): закрыты находки финального ревью цепочки

- Зачем:
  - финальный review должен видеть согласованные PRD, issue, курс, Superset и архитектурные документы.
- Что:
  - обновлены PRD, чекбоксы закрытых issue и журнал coordinator-loop.
  - синхронизированы архитектура, карта репозитория, CONTEXT и курс со startup-history-путём.
  - убраны старые маркеры Superset-геокарты после перехода на Top Countries.
- Проверка:
  - rg-проверки финального review по PRD, issue и Superset-маркерам.
  - git diff --cached --check.

CONTEXT.md

@@ -74,22 +74,21 @@ user_domain_id  (пользователь, постоянный)
 - **`GEN_SEED`** — зерно ГПСЧ генератора (детерминизм случайных решений). Не
   данные, а число.
 - **архивный статический сид** (короткое имя — «статический сид», файлы
-  `data/*.jsonl`) — учебный демо-датасет режима `bootstrap` (уроки 0–6). По
+  `data/*.jsonl`) — кладовка готовых значений для генератора: браузеры,
+  страны, устройства, метки кампаний. По
   [ADR-0006](./docs/adr/0006-generation-as-sole-analytics-source.md)
-  он **выведен из аналитики и стал архивным**: витрины и дашборды переводятся на
-  генерацию. У сида осталась одна временная роль — **кладовка готовых значений**
-  (браузеры, страны, устройства, метки кампаний), откуда генератор берёт «фактуру»
-  для событий. Цель — **совсем убрать файл**, когда генератор научится придумывать
-  фактуру сам (отдельная спека). Профиль ниже — теперь опорные цифры и список
+  он **выведен из аналитики и стал архивным**: витрины, дашборды и курс идут через
+  startup-history/backfill → Kafka → STG → ODS → DDS → DM → Superset. Цель —
+  **совсем убрать файл**, когда генератор научится придумывать фактуру сам
+  (отдельная спека). Профиль ниже — теперь опорные цифры и список
   известных расхождений, а не эталон для подгонки (подгонять генерацию под сид
   число-в-число в ADR-0006 отклонено).
 - **стартовая история стенда** (синонимы — **«стартовый сид»** и **«новый сид»**;
   это не новые значения слова, а та же сущность) — сгенерированное прошлое (заливка `K → ∞` +
   заморозка состояния), с которого живой стенд стартует непрерывно. По ADR-0006
   она **несущая**: именно с неё свежий стенд получает историю с первой минуты.
-  Механизм проектируется — спека
-  [модельного времени](./docs/specs/2026-06-14-generator-model-time-and-startup-history.md);
-  решение про часы — [ADR-0005](./docs/adr/0005-generator-model-clock.md).
+  Механизм реализован через Airflow DAG `generator_control` и служебный чистый
+  путь `make generated-history-analytics`; решение про часы — [ADR-0005](./docs/adr/0005-generator-model-clock.md).
 
 ### Модельное время и масштаб (×K)
 
@@ -100,9 +99,9 @@ user_domain_id  (пользователь, постоянный)
 баг (ключ аналитики — `event_timestamp`). Решение и режимы —
 [ADR-0005](./docs/adr/0005-generator-model-clock.md).
 
-## Почему на демо `Unique Users == Unique Sessions`
+## Почему на статическом сиде `Unique Users == Unique Sessions`
 
-В демо-датасете (`data/*.jsonl`) каждый пользователь имеет **ровно один**
+В архивном статическом сиде (`data/*.jsonl`) каждый пользователь имеет **ровно один**
 `click_id` — связь user↔визит строго 1:1 (проверено: 99 пользователей =
 99 `click_id` в полном файле). Поэтому `uniqExact(user_domain_id)` и
 `uniqExact(click_id)` дают одинаковое число.
@@ -114,9 +113,8 @@ user_domain_id  (пользователь, постоянный)
 (события на визит, доля визитов с одним событием), а различие «пользователь vs
 сессия» объясняется текстом урока.
 
-Синтетический генератор (ветка `feature/data-generator`) проблему не решает, а
-усугубляет: он штампует свежий `click_id` на каждое событие, и `click_id`
-вырождается в «событие». См. `generator/KNOWN_ISSUES.md` на той ветке.
+В аналитическом контуре это больше не опорный сценарий: генератор ведёт
+популяцию пользователей и возвращения во времени.
 
 ## Профиль сид-датасета (измерено 2026-06-10, полные файлы)