## Why

Retry задачи в `failed`/`stuck`, чей торрент ЖИВ в qBittorrent, но в состоянии
ошибки (`error`/`missingFiles`), сейчас повторно отдаёт источник. На живом
сломанном торренте это бесполезно: qBittorrent отвергает дубль, задача уходит в
`downloading`, а на ближайшем тике сверки `classErrored` тут же возвращает её в
`failed` (+ дебаунс уведомления). Пользователю retry выглядит сломанным, а
реальное лекарство (перепроверка/`recheck`/восстановление файлов в qBittorrent)
не подсказано (находка ревью NIT-12).

## What Changes

- **Retry сломанного живого торрента отклоняется**, а не переотдаёт источник.
  Отказ несёт понятное сообщение: починить раздачу (`recheck`/восстановить
  файлы) в qBittorrent и повторить. Состояние задачи не меняется, повторного
  `Add` не происходит.
- Повторный `Add` при retry остаётся только для случая, когда раздачи в
  qBittorrent НЕТ (перецепка к здоровому живому торренту — без `Add`, как и
  раньше).

## Capabilities

### New Capabilities

Нет.

### Modified Capabilities

- `state-reconciliation`: требование «Ручной повтор зависшей/упавшей загрузки из
  транспортов» — ветка живого сломанного торрента меняет исход с «повторно отдать
  источник» на «отклонить с подсказкой про `recheck`». Прочие ветки retry (нет
  раздачи → `Add`; жив и здоров → перецепка без `Add`; сброс базиса `retried_at`)
  без изменений.

## Impact

- **Спеки:** дельта `state-reconciliation` (одно MODIFIED-требование).
- **Код:** `internal/worker/worker.go` — `Retry` (ветка `alive && classErrored`
  → отказ `ErrConflict` с сообщением вместо `reAdd`).
- **Тесты:** `internal/worker/worker_test.go` — отклонение retry на живом
  сломанном торренте (`error`/`missingFiles`), контроль перецепки здорового.
- **Миграции БД:** нет.