Мандат ИИ-агента: поле задачи, модель журнала, миграция (0.85) ...

- ТЗ 0.85: новая §3.20 «Мандат ИИ-агента: доступность, взятие, приёмка,
  журнал» (четыре части: флаг доступности задачи, аренда, приёмка,
  журнал) и правки §3.4 (плоскость приёмки рядом с raw/approved), §3.5
  (экземпляр наследует доступность), §3.10 (тулы и флаг is_user), §3.13
  (момент начисления XP при агентском закрытии), §3.14 (kind'ы task.claimed
  и task.review), §5 (поля Task, таблица TaskEvent, конверт пагинации),
  §7 (этап M5+), §8 (открытый вопрос о ретенции журнала). Отдельным
  абзацем зафиксировано, что ai_eligible — не граница безопасности.
- models.Task: ai_eligible (по умолчанию нет), created_by_kind/created_by_name
  (под фильтр «создано агентом»), done_by_kind, accept_state (плоскость
  приёмки, отдельная от статуса — «done = сделано» сохраняется для XP,
  статистики, теплокарты и спавна регулярных) и аренда: claimed_by_token_id
  (FK mcp_tokens, ON DELETE SET NULL — label токена не уникален, поэтому
  сравнивать арендатора можно только по id), claimed_by_name, claimed_at,
  claim_expires_at. Свойства claim_is_alive и claimed_by: протухшая аренда
  наружу не показывается. Индексы (user_id, ai_eligible/accept_state/
  created_by_kind).
- models.TaskEvent — журнал «кто, что и когда»: task_id обнуляется при
  удалении задачи (ON DELETE SET NULL), заголовок хранится снапшотом, иначе
  записи умирали бы вместе с задачей. Актор (actor_kind/actor_name/via),
  комментарий, вид события.
- schemas: TaskCreate.ai_eligible, TaskUpdate.ai_eligible и close_comment
  (не поле задачи — уходит в событие закрытия, как earned_via), поля мандата
  в TaskOut, новые TaskEventOut/TaskEventPage/AcceptIn.
- services/recurrence._copy: новый экземпляр регулярной задачи наследует
  доступность агенту и автора правила.
- Миграция a1b2c3d4e5f7 (после d4e5f6a7b8c9): поля и индексы tasks, таблица
  task_events. Существующие задачи бэкфиллятся server_default — «не доступно
  агенту, создано пользователем»; accept_state и done_by_kind остаются NULL,
  приёмка к старым закрытиям не применяется.

ТЗ 0.85.

Мультиюзерность: изоляция данных, per-user MCP-токены, claim при первом логине (ТЗ 0.34, бэкенд) ...

- Модели: User (профиль из SSO), McpToken (только sha256-хэш),
  user_id на tasks/projects/tags/documents/xp_events/coin_events/garden_items;
  уникальности имени проекта/тега — составные (per-user); app_settings →
  per-user (PK user_id+key), старая таблица → app_settings_global (источник claim)
- Миграция f9a0b1c2d3e4 (Postgres): новые таблицы, user_id на 7 таблиц,
  составные уникальности, частичные индексы дейли/уровня per-user
- Claim-on-first-login (ТЗ 1.2): первый вошедший забирает строки с user_id NULL
  и копирует глобальные настройки; upsert профиля в callback
- Scoping всех API и сервисов: tasks/projects/tags/attachments/settings/xp/
  garden + xp/garden/closing/options/recurrence/detailing; чужое — 404
- MCP (ТЗ 3.10): per-user bearer-токены вместо env MCP_TOKEN (middleware →
  sha256 → request.state.gntodo_user_id), 8 тулов с Context; SSE publish(uid)
- API /api/mcp-tokens: список/генерация (plaintext один раз)/отзыв
- Тесты: test_multiuser (изоляция двух пользователей, claim, per-user дейли/
  настройки), test_mcp_tokens; 135 passed, ruff, mypy strict

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

Дедлайны и регулярные задачи (ТЗ 3.4, 3.5) ...

- дедлайны двух видов: строгий (deadline_date) и нестрогий
  (deadline_period: день/неделя/месяц/год); бейджи в дереве и списке,
  просроченные — красным
- регулярные задачи: три правила (интервал N дней, дни недели, день месяца),
  якорь — фиксированный календарь от даты выполнения; при завершении
  автоматически рождается следующий экземпляр (API и MCP)
- «3 варианта»: срочность дедлайнов влияет на отбор (просроченные и близкие
  строгие — первыми, затем нестрогие периоды)
- ТЗ 0.4: вопросы 8.1–8.3 помечены решёнными (правила повторения, прогноз,
  валюта)

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