## Why

Спека `download-tracking` требует перечитывать `source_type` под блокировкой
переходов **непосредственно перед добавлением**, а `processCatched` перечитывает
запись под блокировкой сразу после тик-снимка — до вызова namer'а, который идёт
секунды вне блокировки. Апгрейд пойманной magnet-задачи до `.torrent`, легший
ровно в окно namer'а, оставляет `addReq` из устаревшего снимка: код добавит
magnet, хотя в БД уже `source_type = torrent`. Заявленное расходится с
фактическим, и аудит capability это поймал.

Расхождение закрывается приведением спеки к коду: рациональ требования — «не
полагаться на снимок, снятый ранее вне блокировки» — первым re-read уже
выполнен, а остаточное namer-окно принимается как **известное ограничение с
названной ценой**. Цена такая: на закрытом трекере magnet зависает в `metaDL`,
через `magnet_timeout` задача уходит в `failed` и сама оттуда не поднимается —
восстановление требует ручного шага (убрать зависшую раздачу из qBittorrent),
после которого `Retry` добавит сохранёнными байтами. Подробности маршрута и
почему «`Retry` добьёт сам» неверно — `design.md`, решение D2. Пока спека
утверждает недостижимую гарантию, следующий аудит поймает то же самое заново, а
читатель спеки будет считать окно закрытым.

## What Changes

- Требование о re-read `source_type` переформулируется: перечитывать **под
  блокировкой переходов после тик-снимка**, перед подготовкой запроса на
  добавление, — вместо «непосредственно перед добавлением».
- Остаточное окно между этим re-read и `qbt.Add` (вывод имени через LLM) явно
  названо известным ограничением, с достоверным маршрутом восстановления: на
  публичном трекере ущерба нет вовсе; на закрытом magnet зависает в `metaDL`,
  предохранитель `magnet_timeout` уводит в `failed`, откуда задача сама не
  поднимается — нужен ручной шаг (убрать зависшую раздачу), после которого
  `Retry` добавит сохранёнными байтами.
- Добавляется сценарий на апгрейд в окне namer'а с исходом «добавлен magnet из
  снимка → `magnet_timeout` → `failed` → ручной шаг + `Retry`»; существующий
  сценарий на апгрейд между тик-снимком и re-read фиксируется явно.
- Называется исход ветки «сохранённые байты `.torrent` недоступны»: `add` не
  выполняется, загрузка остаётся в `catched`, отсечка — `catch_timeout`.
  Требование впервые называет шаг подготовки запроса, и его провал до сих пор не
  был заказан ни одним сценарием.
- В `ingest` снимается парная ложная гарантия: обещание «воркер добавит раздачу
  файлом (не по magnet)» обусловливается тем, что апгрейд лёг до подготовки
  запроса, и получает сценарий на окно со ссылкой на `download-tracking`. Иначе
  ложная гарантия не убирается, а переезжает в соседнюю capability.

Изменение не ломающее: наблюдаемое поведение системы прежнее, меняется только
заявленное.

## Capabilities

### New Capabilities

Нет.

### Modified Capabilities

- `download-tracking`: требование «Добавление пойманной загрузки в qBittorrent»
  — момент re-read `source_type` относительно тик-снимка и namer'а, признание
  остаточного окна с его ценой и маршрутом восстановления, исход при
  недоступных байтах, три новых сценария.
- `ingest`: требование «Приём источника из `.torrent`-файла» — обещание «воркер
  добавит раздачу файлом» обусловливается моментом апгрейда, добавляется
  сценарий на окно.

## Impact

- `openspec/specs/download-tracking/spec.md` — текст требования и сценарии.
- `openspec/specs/ingest/spec.md` — обусловленное обещание и сценарий на окно.
- `internal/worker/worker.go` (`processCatched`) — только чтение как источник
  фактического поведения; правок нет.
- `internal/worker/catched_test.go` — `TestProcessCatchedReReadsSourceTypeUnderLock`
  остаётся оракулом первого re-read; правок нет.
- Кода, схемы БД, конфига и внешних контрактов изменение не касается.
