Retry/stall: сброс базиса таймаута + простой от last_activity (MAJOR-1, MAJOR-2)

Два связанных бага семантики таймаутов зависания и ручного retry.

MAJOR-1: Retry живого торрента не сбрасывал базис отсчёта таймаута — задача
мгновенно снова падала в stuck на ближайшем тике. Вводим колонку
download.retried_at (миграция 0010): ручной retry фиксирует момент и
приподнимает пол обоих таймаутов (max(базис, retried_at)). Хранится в БД, а
не в памяти, чтобы сброс пережил тик поллинга и рестарт.

MAJOR-2: stuck_after мерил ВОЗРАСТ торрента (от added_on), а не ПРОСТОЙ —
долго качавшийся торрент, на миг зашедший в stalledDL, ложно уходил в stuck
со «stalled for 5h». Теперь stuck_after мерит простой от qBit last_activity
(новое поле qbt.Torrent из того же ответа /torrents/info); magnet_timeout
по-прежнему мерит возраст (семантически верно). checkTimeouts разбит на
torrentAge/stallDuration/addedBasis/retriedFloor.

NIT-10: фолбэк базиса возраста added_on→created_at сохранён и покрыт.
NIT-12: retry перестаёт перецепляться к сломанному живому торренту
(error/missingFiles) — повторно отдаёт источник (перецепка к нему
бессмысленна: reconcile тут же вернул бы в failed).

Спека: дельта state-reconciliation (MODIFIED «Восстановление зависшей
загрузки» и «Ручной повтор»), правка docs/specs/workflow.md (устранено
противоречие «возраст vs простой»), ER-схема database.md.

Тесты: TestRetryResetsTimeoutBasis (следующий тик после retry — прячется в
TestRetryReattachesNoReadd), TestStallMeasuredFromLastActivity,
TestSetRetriedAtOverwrites.

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

docs/specs/workflow.md

@@ -157,12 +157,17 @@ SQLite; `worker` периодически сверяет qBittorrent с БД и
 - **ещё качается:** `downloading`/`stalledDL`/`metaDL`/`forcedMetaDL`/
   `queuedDL`/`checkingDL`/`forcedDL`/`pausedDL`/`stoppedDL`.
 - **застряло по таймауту (страховка):** `metaDL`/`forcedMetaDL` дольше
-  `magnet_timeout` → `failed`; `stalledDL` дольше `stuck_after` → `stuck`.
-  `magnet_timeout` — **редкий страховочный предохранитель** (дефолт `24h`), а
-  не рабочий механизм: долгий `metaDL` (медленные трекеры/мало пиров) — это
-  норма, его не убиваем агрессивно. Возраст считаем от времени добавления
-  торрента в qBittorrent (`added_on`), а не от создания задачи (базис
-  переживает retry и усыновление).
+  `magnet_timeout` → `failed`; `stalledDL` **простаивающий** дольше
+  `stuck_after` → `stuck`. `magnet_timeout` — **редкий страховочный
+  предохранитель** (дефолт `24h`), а не рабочий механизм: долгий `metaDL`
+  (медленные трекеры/мало пиров) — это норма, его не убиваем агрессивно. Меры у
+  двух таймаутов **разные**: `magnet_timeout` мерит **возраст** торрента от
+  добавления в qBittorrent (`added_on`, фолбэк `created_at`); `stuck_after`
+  мерит **длительность простоя** — от `last_activity` (последнее движение
+  данных), а не возраст, иначе долго качавшийся торрент, на миг зашедший в
+  `stalledDL`, ложно уходит в `stuck` со «stalled for 5h». Оба базиса
+  приподнимаются до `retried_at` — ручной retry сбрасывает отсчёт, чтобы возврат
+  в `downloading` не ронял задачу снова на ближайшем тике.
 - **ошибка:** `error`/`missingFiles` → `failed` (`error_code` `qbit_error`) —
   это настоящий провал, в отличие от таймаута.
 
@@ -181,8 +186,10 @@ SQLite; `worker` периодически сверяет qBittorrent с БД и
   всё ещё в `metaDL`/`stalledDL`, задача остаётся упавшей (без зацикливания).
   Настоящие провалы (`qbit_error`) сверкой не воскрешаются.
 - Дополнительно доступен **ручной retry** из веб-UI и Telegram (не только
-  REST): возвращает в `downloading`, перецепляясь к живому торренту без
-  повторного `Add`.
+  REST): возвращает в `downloading`, перецепляясь к живому **здоровому** торренту
+  без повторного `Add` (к сломанному — `error`/`missingFiles` — не
+  перецепляемся, повторно отдаём источник) и сбрасывая базис таймаутов
+  (`retried_at`), чтобы задача не упала снова на ближайшем тике.
 
 Пути файлов берём из API (`save_path` + относительные имена из
 `/torrents/files`, уже включающие корневую папку торрента), не из