OpenSpec: архивация трёх параллельных changes + синк спек

Итог параллельной волны фиксов (worktree-изоляция, cherry-pick в master):
- ingest-dedup-integrity (F1, F6) → спека ingest
- retry-stall-basis (MAJOR-1, MAJOR-2) → спека state-reconciliation
- linking-transition-robustness (MAJOR-4, MINOR-7) → спеки file-layout
  и state-reconciliation

Дельты влиты в openspec/specs, changes перенесены в
openspec/changes/archive/2026-07-08-*. Беклог не трогаю (по решению).

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

openspec/specs/ingest/spec.md

@@ -207,10 +207,13 @@ btih (v1), и btmh (v2); `kind` определяется по длине hex (40
 (повторного добавления торрента в qBittorrent).
 
 Та же проверка SHALL применяться к дозаписи хешей загрузке (раскрытие
-гибридного торрента): хеш, которым владеет другая активная загрузка,
-дописан быть SHALL NOT. Прямой перевод терминальной загрузки в активное
-состояние в обход этой проверки SHALL отклоняться хранилищем (механический
-бэкстоп вместо удалённого unique-индекса).
+гибридного торрента) на ВСЕХ путях дозаписи, включая дедуп-дозапись при
+приёме: хеш, которым владеет другая активная загрузка, дописан быть SHALL
+NOT — ни отдельным методом дозаписи, ни дедуп-веткой атомарного заведения,
+которая доносит недостающие хеши найденной активной задаче. Прямой перевод
+терминальной загрузки в активное состояние в обход этой проверки SHALL
+отклоняться хранилищем (механический бэкстоп вместо удалённого
+unique-индекса).
 
 #### Scenario: Retry при занятом хеше
 
@@ -220,6 +223,16 @@ btih (v1), и btmh (v2); `kind` определяется по длине hex (40
 - **THEN** переход отклоняется с пояснением, #1 остаётся в `failed`
 - **AND** активной по `h` остаётся #2
 
+#### Scenario: Дедуп-дозапись не крадёт чужой хеш
+
+- **GIVEN** активная загрузка A владеет хешем `v1`, активная загрузка B
+  владеет хешем `v2` того же гибридного торрента
+- **WHEN** принимается источник с обоими хешами `{v1, v2}` и дедупится на B
+- **THEN** B получает только незанятые хеши, а `v1` (в собственности A) B не
+  дописывается
+- **AND** инвариант «не более одной активной загрузки на infohash»
+  сохраняется (по `v1` активна только A)
+
 ### Requirement: Синтез контекста распознавания из полей magnet
 
 При приёме система SHALL извлекать из полей magnet-ссылки дополнительный
@@ -314,7 +327,6 @@ recognition (LLM-промпт) и веб-UI (страница загрузки).
 - **THEN** `download.Context` остаётся пустым
 - **AND** приём проходит штатно (пустой контекст допустим)
 
-
 ### Requirement: Приём источника из .torrent-файла
 
 Приём SHALL принимать источник в виде **байтов `.torrent`-файла** (наряду с
@@ -342,9 +354,21 @@ v2-хеш (для v2/гибридного файла, BEP52) SHALL извлек
 чтобы воркер мог добавить источник в qBittorrent именно файлом (не по magnet):
 раздачи закрытых трекеров и торренты без DHT по magnet-хешу метаданные не
 получат. Сохранение байтов SHALL выполняться в той же write-транзакции, что и
-заведение загрузки; при дедупликации (новая загрузка не создана) байты
-сохраняться SHALL NOT. Размер принимаемого `.torrent` система SHALL ограничивать
-на границе транспорта (защита от разбухания хранилища).
+заведение загрузки; при дедупликации (новая загрузка не создана) байты в общем
+случае сохраняться SHALL NOT.
+
+**Исключение — апгрейд пойманной magnet-задачи до torrent.** Если входящий
+источник — байты `.torrent`, а дедуп попал на активную загрузку с
+`source_type = magnet`, ещё НЕ отданную в qBittorrent (состояние `catched`),
+система SHALL в одной write-транзакции сохранить байты `.torrent`,
+привязав их к этой загрузке, и сменить её `source_type` на `torrent`. Тем
+самым воркер добавит раздачу файлом, а не magnet-хешем (иначе на закрытом
+трекере без DHT метаданные не докачаются, а magnet застрянет в metaDL →
+failed). Апгрейд SHALL применяться ТОЛЬКО пока загрузка в `catched` (воркер
+источник ещё не добавил); для уже добавленной (`downloading` и далее)
+загрузки смена `source_type` при дедупе выполняться SHALL NOT — её судьба
+решается путями retry/сверки, а не приёмом. Апгрейд SHALL быть best-effort:
+его неуспех приём не прерывает.
 
 Из полей `.torrent` система SHALL синтезировать контекст распознавания (имя
 раздачи, суммарный размер, сигнал по дереву файлов, домен трекера, комментарий)
@@ -380,12 +404,31 @@ NOT.
   qBittorrent
 - **AND** сопоставление раздачи работает по нему
 
-#### Scenario: Дубль .torrent по активной задаче
+#### Scenario: Дубль .torrent по активной torrent-задаче
 
-- **GIVEN** уже есть активная (в т.ч. `catched`) загрузка с тем же infohash
+- **GIVEN** уже есть активная (в т.ч. `catched`) загрузка с тем же infohash и
+  `source_type = torrent`
 - **WHEN** принимается `.torrent` с тем же инфохэшем
 - **THEN** новая загрузка не создаётся, возвращается существующая
-- **AND** байты торрента не сохраняются (дубль)
+- **AND** байты торрента повторно не сохраняются (дубль)
+
+#### Scenario: Апгрейд catched-magnet до torrent
+
+- **GIVEN** активная загрузка в `catched` с `source_type = magnet` и хешем `h`
+  (magnet-задача ещё не отдана в qBittorrent)
+- **WHEN** принимается `.torrent` с тем же инфохэшем `h`
+- **THEN** новая загрузка не создаётся, возвращается существующая
+- **AND** байты `.torrent` сохраняются привязанными к ней, а её `source_type`
+  становится `torrent` — в одной транзакции
+- **AND** воркер добавит раздачу файлом (не по magnet)
+
+#### Scenario: Magnet-задача уже добавлена — апгрейда нет
+
+- **GIVEN** активная загрузка с `source_type = magnet` уже в `downloading`
+  (отдана в qBittorrent)
+- **WHEN** принимается `.torrent` с тем же инфохэшем
+- **THEN** возвращается существующая загрузка, её `source_type` остаётся
+  `magnet`, байты `.torrent` не сохраняются
 
 #### Scenario: Контекст из полей файла
 
@@ -398,3 +441,4 @@ NOT.
 
 - **WHEN** принимаемый `.torrent`-файл превышает ограничение размера
 - **THEN** приём отклоняется с ошибкой, загрузка не создаётся
+