Рефакторинг границ capabilities: цепочка загрузка→матч→ревью→раскладка (openspec)

Привёл набор capabilities в OpenSpec к цепочке обработки, чтобы имя capability
отвечало одному поведению. Чисто по спекам, код и поведение системы не меняются.

Change refactor-capability-boundaries (архивирован):
- recognition разделён на recognition (разбор LLM) + metadata-match (сверка с базами)
- review выделен из web-ui + мигрирован из docs/specs/review-ux.md
- новые capability из docs/specs: file-layout, download-tracking, notifications
- identity очищен до инфра-id; приём (инфохэши, дедуп, ядро приёма) — в ingest
- уведомление о рассинхроне перенесено из state-reconciliation в notifications
- дубль владения путём и безопасного undo оставлен в state-reconciliation

Итог: 11 capabilities, openspec validate --strict проходит (+37/−11 требований).
Источник истины по мигрированным темам переехал в openspec/specs (шапки в docs).
Снят пункт беклога «Пересмотр набора capabilities».

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

openspec/specs/notifications/spec.md

@@ -0,0 +1,56 @@
+# notifications Specification
+
+## Purpose
+Уведомление автора загрузки о значимых событиях: падения (`failed`/`stuck`,
+включая приёмный `qbit_add` мимо поллинга) с дебаунсом повторов, приглашение в
+`review` и готовность, рассинхрон (`orphaned`/`target_missing`). Единое место
+доставки пингов, над которым транспорты (Telegram и др.) — тонкие адаптеры.
+## Requirements
+### Requirement: Уведомление о падении загрузки
+
+Любой переход загрузки в `failed`/`stuck` система SHALL сопровождать уведомлением
+автора загрузки через настроенный механизм (`notifier`), чтобы падение не
+оставалось незамеченным. Это SHALL включать приёмное падение `qbit_add` (не
+удалось добавить раздачу в qBittorrent), которое идёт мимо поллинг-цикла worker.
+
+#### Scenario: Уведомление при падении приёма
+
+- **GIVEN** приём загрузки, где добавление в qBittorrent не удалось
+- **WHEN** загрузка помечается `failed` с `error_code` `qbit_add`
+- **THEN** автор загрузки получает уведомление о падении
+
+### Requirement: Дебаунс повторных падений
+
+Повторные падения одной задачи в пределах окна дебаунса система SHALL уведомлять
+лишь один раз, чтобы мерцающий stalled-торрент (`stuck` ↔ `downloading`) не спамил
+автора.
+
+#### Scenario: Мерцающий stalled не спамит
+
+- **GIVEN** задача, многократно переходящая `stuck` ↔ `downloading` в пределах окна дебаунса
+- **WHEN** происходят повторные падения
+- **THEN** уведомление отправляется один раз за окно
+
+### Requirement: Пинг о входе в review и готовности
+
+При переходе загрузки в `review` система SHALL пинговать автора (сообщение в
+Telegram / бейдж в вебе) — пользователя зовут, а не он опрашивает. После
+успешного применения (готовность) система SHALL показывать, что создано.
+
+#### Scenario: Пинг при входе в review
+
+- **GIVEN** загрузка переходит в `review`
+- **WHEN** происходит переход
+- **THEN** автор получает пинг с приглашением подтвердить раскладку
+
+### Requirement: Уведомление о рассинхроне
+
+При переходе задачи в `orphaned` или `target_missing` система SHALL
+уведомлять автора загрузки через настроенный механизм уведомлений
+(`notifier`), чтобы рассинхрон не оставался незамеченным.
+
+#### Scenario: Уведомление при потере источника
+
+- **WHEN** задача переходит в `orphaned`
+- **THEN** автор загрузки получает уведомление о рассинхроне
+