specs: правки по дозапущенному архитектурному проходу

- термин «тик-снимок» определён при первом употреблении
- маршрут восстановления в download-tracking больше не пересказывает
  правила Retry — только ссылается на state-reconciliation
- заголовок сценария ingest не обещает исхода, которого сценарий не даёт

openspec/changes/archive/2026-08-06-catched-source-type-reread-wording/specs/ingest/spec.md

@@ -101,7 +101,7 @@ NOT.
   подготовки запроса на добавление — см. `download-tracking` «Добавление
   пойманной загрузки в qBittorrent»
 
-#### Scenario: Апгрейд в окне вывода имени — воркер добавит magnet
+#### Scenario: Апгрейд в окне вывода имени — гарантия добавления файлом не даётся
 
 - **GIVEN** активная загрузка в `catched` с `source_type = magnet`, для которой
   воркер уже подготовил запрос на добавление и выводит отображаемое имя

openspec/specs/download-tracking/spec.md

@@ -137,7 +137,8 @@ Conflict`), и загрузка зациклилась бы на ретраях.
   magnet-хешу вместо файла система SHALL NOT.
 
 `source_type` для выбора способа добавления worker SHALL перечитывать **под
-блокировкой переходов после тик-снимка** — перед подготовкой запроса на
+блокировкой переходов после тик-снимка** (тик-снимок — снимок списка `catched`,
+снятый на тике поллинга) — перед подготовкой запроса на
 добавление, а не полагаясь на снимок списка `catched`, который к моменту
 обработки загрузки уже устарел (блокировка между снятием списка и обработкой
 отпускается). Иначе апгрейд пойманной magnet-задачи до `.torrent` (см.
@@ -163,11 +164,9 @@ worker `add` выполнять SHALL NOT и SHALL оставлять загру
 ущерба нет вовсе. На закрытом трекере, ради которого `.torrent` и подавался,
 magnet без метаданных зависает в `metaDL`, и предохранитель `magnet_timeout`
 уводит задачу в `failed` (см. «Таймауты-предохранители downloading»). Сама собой
-задача из этого состояния не восстанавливается: фоновая сверка оживляет только
+задача из этого состояния не восстанавливается, и `Retry` её тоже не чинит —
-продвинувшийся источник, а `Retry` при живом и здоровом торренте (`metaDL`
+почему, см. `state-reconciliation` «Ручной повтор зависшей/упавшей загрузки из
-считается живым) перецепляется к нему и повторный `add` по актуальному
+транспортов». Восстановление сегодня требует
-`source_type` не делает — см. `state-reconciliation` «Ручной повтор
-зависшей/упавшей загрузки из транспортов». Восстановление сегодня требует
 ручного шага: убрать
 зависшую magnet-раздачу из qBittorrent, после чего `Retry` добавит источник
 заново по актуальному `source_type` — сохранёнными байтами, которые апгрейд уже

openspec/specs/ingest/spec.md

@@ -575,7 +575,7 @@ NOT.
   подготовки запроса на добавление — см. `download-tracking` «Добавление
   пойманной загрузки в qBittorrent»
 
-#### Scenario: Апгрейд в окне вывода имени — воркер добавит magnet
+#### Scenario: Апгрейд в окне вывода имени — гарантия добавления файлом не даётся
 
 - **GIVEN** активная загрузка в `catched` с `source_type = magnet`, для которой
   воркер уже подготовил запрос на добавление и выводит отображаемое имя