Регулярные задачи: дата следующего раза, метка в списке, фильтр (0.91) ...

Дата следующего экземпляра считалась и выбрасывалась: закрыв ежедневную
задачу, владелец видел её же снова «к выполнению», без даты и неотличимо от
задачи на сегодня. Теперь дата ложится в существующее `deadline_date` (новых
полей и миграций нет) — при нестрогом периоде не ставится, ТЗ 3.4 запрещает
оба поля разом.

- recurrence: `_copy` получает посчитанную дату, `spawn_next` её не теряет;
- reminders: у регулярной повод один — ритм, дедлайновые правила её не
  касаются (иначе в день срока два уведомления об одном деле), сводка тоже;
- reminders: ключ дедупа ритма включает id задачи — без него уникальность
  push_deliveries съедала второе «Пора», и за день приходило одно
  напоминание на пользователя, сколько бы регулярных ни совпало;
- API: параметр `task_type` у GET /api/tasks;
- список: переключатель «Регулярные» рядом с «Приоритетными»;
- карточка: акцентная полоса по левой кромке и кружок с иконкой повтора
  перед названием, подсказка словами о правиле; дата читается как
  «след. 12.10.2026»;
- ачивка «Дедлайн-босс» регулярные не считает.

ТЗ 0.91: §3.5, §3.6, §3.21, §5, §7.

Мультиюзерность: изоляция данных, 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>

Пачка 2 ревью: общий путь закрытия — MCP-награды и анти-дюп спавна ...

- Новый services/closing.py: handle_task_closed — спавн регулярной + XP +
  монеты + бонус уровня; используют и HTTP-API, и MCP-инструменты. Закрытие
  агентом теперь даёт те же награды, что и UI (ТЗ 3.5, 3.13, 3.10).
- Задача.spawned_at (+миграция): спавн — один раз на цепочку; раньше MCP
  спавнил следующий экземпляр при каждом обновлении закрытой задачи.
- Выход из done сбрасывает done_at (HTTP и MCP): повторное закрытие снова
  проходит через ветку закрытия без дублей наград (открытый вопрос ТЗ 7).
- MCP create_task: микронаграда за создание, как в HTTP-API; broadcast
  xp.changed (celebrate:true при закрытии, false при создании).
- Тесты: MCP-награды при закрытии и создании, спавн ровно один раз,
  un-done/повторное закрытие без дублей (HTTP и MCP). 109 passed.
  ТЗ 0.28.

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>