Рефакторинг границ 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>

docs/specs/workflow.md

@@ -1,5 +1,12 @@
 # Жизненный цикл загрузки и машина состояний
 
+> **Источник истины переехал в OpenSpec.** Прямой путь FSM (downloading →
+> completed → stuck/failed, поллинг, усыновление) — `openspec/specs/
+> download-tracking/`; сверка с реальностью — `openspec/specs/
+> state-reconciliation/`; уведомления — `openspec/specs/notifications/`. Этот
+> файл — справочный нарратив по графу состояний; при расхождении верна спека
+> OpenSpec.
+
 Как загрузка проходит путь от приёма источника до разложенных файлов:
 состояния, переходы и то, что их вызывает. Кто владеет переходами и общее
 устройство — в [architecture.md](architecture.md); детали распознавания —