feat: разбор и хранение тренировок и состояния разума

- секции `workouts` и `stateOfMind` покрыты разбором: тренировка лежит одной
  строкой вместе с маршрутом и внутренними рядами, запись — по ключу `род + id`;
  миграция 00007 заводит обе таблицы и возвращает в очередь `partial`-доставки
  с этими ключами
- сущность заменяется целиком, но условно: приехавшая побеждает, если не теряет
  содержания сохранённой (множество ключей и длины верхнеуровневых массивов), а
  при равном содержании выигрывает версия из более поздней доставки ЖУРНАЛА —
  «побеждает приехавшая» было бы функцией порядка свёртки, и живая витрина
  расходилась бы с пересборкой молча
- отпечаток витрины покрывает тренировки и записи и снимается одним снимком
  базы; отчёт `reindex` считает «было и стало» по каждой единице хранения

docs/backlog/read-api-tochki.md

@@ -14,8 +14,17 @@
 и не влезает — ошибка со списком доступных сеток, а не тихая подмена. Различие
 существенно: иначе агент, попросивший минутную сетку, получит суточные суммы.
 
+**Отдача тренировок и записей входит сюда же.** Разбор и хранение сущностей с
+собственным `id` сделаны (change `2026-08-02-trenirovki-i-zapisi`), а эндпоинтов
+нет: тренировка с маршрутом и записи `stateOfMind` лежат в витрине и наружу не
+отдаются. Вводить их раньше конверта ответа значило бы задать контракт
+мимоходом, поэтому `GET /workouts`, `GET /workouts/{id}` и
+`GET /records/{kind}` закрываются этой задачей — вместе с формой конверта и
+правилом размера ответа. Второй сценарий паспорта (трекер) до тех пор не закрыт.
+
 Готово, когда «шаги за неделю по дням» и «вес за год» отвечаются одним запросом
-каждый, а в ответе всегда видно `layer`, `bucket` и `aggregation`.
+каждый, тренировка отдаётся одним пакетом вместе с маршрутом, а в ответе всегда
+видно `layer`, `bucket` и `aggregation`.
 
 Связано: `docs/architecture.md` → «Read API», план → шаг «Read API».