Идентичность на ULID: download_infohash, guarded-дедуп, миграция (ulid-identity)

Все сущности переехали с INTEGER AUTOINCREMENT на TEXT ULID (lowercase,
internal/ident — единая точка генерации и разбора; oklog/ulid). Инфохэши
загрузки — множество (download_infohash, v1/v2 гибридных торрентов): дедуп
и сопоставление в поллинге по любому из хешей, magnet-парсер отдаёт оба
хеша гибридной ссылки, усечённый v2-хеш v2-only раздач не хранится.

Инвариант «не более одной активной загрузки на infohash» вместо снятого
unique-индекса держат guarded-методы store в одной write-транзакции
(_txlock=immediate): CreateDownloadIfNoActive (приём/adopt, с доносом
недостающих хешей), ActivateIfNoOtherActive (retry/recovery/relink, отказ
до побочных эффектов), guarded AddInfohashes; SetDownloadState отклоняет
терминал→активное как механический бэкстоп.

Миграция 0006 — первая Go-миграция goose: пересоздание таблиц при
включённых FK, backfill ULID с timestamp из created_at (хронология id
сохранена), разнос infohash, удаление idempotency_key. BREAKING: формат id
в URL/логах/Telegram, REST-поля id (string) и infohashes (список).

Новая конвенция docs/conventions/database.md (без числовых PK), корреляция
в логах grep'ом по голому ULID, ER-схема обновлена. Спеки: новая capability
identity, MODIFIED в state-reconciliation; change заархивирован. Пройдены
ревью дизайна и кода (по 8 углов), все находки исправлены с
регрессионными тестами.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

openspec/changes/archive/2026-07-02-ulid-identity/specs/state-reconciliation/spec.md

@@ -0,0 +1,113 @@
+# state-reconciliation — дельта для ulid-identity
+
+Механика идемпотентности меняется: снимаемый/восстанавливаемый
+`idempotency_key` исчезает, инвариант «не более одной активной задачи на
+infohash» обеспечивается проверкой активности по `download_infohash`
+(см. capability `identity`).
+
+## MODIFIED Requirements
+
+### Requirement: Периодическая сверка состояния с реальностью
+
+`worker` SHALL периодически (на тике поллинга) сверять задачи, для которых
+ожидаются разложенные файлы, с фактом на файловой системе и в qBittorrent, и
+выводить состояние задачи из двух независимых признаков: присутствия
+**источника** (раздача, совпавшая с **любым из известных хешей** загрузки в
+`download_infohash`, в выдаче qBittorrent) и присутствия **цели** (см.
+требование о владении целевым путём: существуют все ссылки последнего батча
+со статусом раскладки, всё ещё принадлежащие этой загрузке).
+
+Сверке по матрице «источник × цель» SHALL подвергаться состояния `done`,
+`target_missing`, `orphaned`. Состояние `deleted` сверка трогать SHALL NOT —
+оно терминально. Активные (`downloading`/`recognizing`/`review`/`deferred`/
+`linking`) и пользовательски-терминальные (`reverted`/`cancelled`) состояния
+сверка по матрице трогать SHALL NOT.
+
+**Восстановимые** `failed`/`stuck` (с `error_code` `magnet_timeout` или
+`stalled` — задержки, вызванные нашей нетерпеливостью, а не реальной ошибкой)
+сверка SHALL рассматривать отдельно — на предмет оживления источника (см.
+требование о восстановлении зависшей загрузки), не по матрице «источник ×
+цель». Прочие `failed` (например `qbit_error`) сверка трогать SHALL NOT.
+
+Состояние SHALL переписываться только при его изменении (без записи и логов,
+когда выведенное состояние совпадает с текущим).
+
+#### Scenario: Источник и цель на месте — состояние не меняется
+
+- **WHEN** для задачи в `done` раздача присутствует в qBittorrent и все её
+  разложенные хардлинки существуют
+- **THEN** задача остаётся в `done`
+- **AND** запись состояния и лог перехода не выполняются
+
+#### Scenario: Частичная пропажа цели считается отсутствием
+
+- **WHEN** часть разложенных хардлинков задачи удалена, а источник на месте
+- **THEN** цель считается отсутствующей и задача переходит в `target_missing`
+
+#### Scenario: Задача в deleted сверкой не переоценивается
+
+- **WHEN** задача находится в `deleted`
+- **THEN** сверка её не рассматривает и состояние не меняет, даже если по её
+  бывшему пути появился файл другой загрузки
+
+#### Scenario: Провал по ошибке qBittorrent восстановлению не подлежит
+
+- **WHEN** задача в `failed` с `error_code` `qbit_error`
+- **THEN** сверка её не рассматривает и состояние не меняет
+
+### Requirement: Восстановление зависшей загрузки при оживлении источника
+
+Система SHALL возвращать в активный поток задачу, упавшую из-за нашей
+нетерпеливости (`failed`/`magnet_timeout` или `stuck`/`stalled`), если её
+источник в qBittorrent жив и продвинулся: переход выводится из текущего
+состояния торрента так же, как при штатной сверке загрузки
+(`uploading`/`stalledUP`/… → `completed`; `downloading`/`metaDL`/… →
+`downloading`). Восстановление SHALL опираться на фактическое состояние
+торрента в qBittorrent, а не на время с момента создания записи.
+
+После возврата в любое нетерминальное состояние (`downloading` или
+`completed`) повторный приём того же infohash SHALL снова дедуплицироваться
+на эту задачу: активность задачи выводится только из её `state`, отдельный
+восстанавливаемый ключ идемпотентности отсутствует. Если за время простоя в
+`failed`/`stuck` тем же infohash (любым из хешей задачи) уже завладела
+другая активная задача (новый приём, пока эта лежала упавшей), система
+SHALL NOT воскрешать упавшую задачу и SHALL оставить её в `failed`/`stuck`,
+сохраняя инвариант «не более одной активной задачи на infohash».
+
+`magnet_timeout`/`stalled` SHALL быть редким страховочным исходом, а не
+рабочим механизмом: пока торрент в `metaDL`/`forcedMetaDL` или иным образом
+прогрессирует в пределах страховочного таймаута, задача в `failed`/`stuck`
+из-за него оказаться SHALL NOT (см. требование о терпеливости к долгим
+метаданным в `docs/specs/workflow.md`).
+
+#### Scenario: Метаданные пришли после magnet_timeout
+
+- **GIVEN** задача в `failed` с `error_code` `magnet_timeout`, а её торрент
+  в qBittorrent уже получил метаданные и качается (`downloading`)
+- **WHEN** срабатывает фоновая сверка
+- **THEN** задача возвращается в `downloading`
+- **AND** повторный приём того же infohash снова дедуплицируется на неё
+
+#### Scenario: Торрент уже завершился, пока задача была в failed
+
+- **GIVEN** задача в `failed` с `error_code` `magnet_timeout`, а её торрент
+  в qBittorrent уже готов к раскладке (`uploading`/`stalledUP`)
+- **WHEN** срабатывает фоновая сверка
+- **THEN** задача переходит в `completed` и продолжает обычный поток
+  (распознавание/раскладка)
+
+#### Scenario: Источник так и не ожил — состояние не меняется
+
+- **GIVEN** задача в `failed` с `error_code` `magnet_timeout`, а её торрент
+  всё ещё висит в `metaDL` без метаданных (или отсутствует в qBittorrent)
+- **WHEN** срабатывает фоновая сверка
+- **THEN** задача остаётся в `failed`
+
+#### Scenario: infohash уже занят другой активной задачей
+
+- **GIVEN** задача #1 в `failed`/`magnet_timeout`, а тем же infohash уже
+  владеет другая активная задача #2 (приём повторили, пока #1 лежала упавшей)
+- **WHEN** источник ожил (торрент получил метаданные или готов) и сверка
+  пытается воскресить #1
+- **THEN** #1 остаётся в `failed` (восстановление не выполняется)
+- **AND** активной по этому infohash остаётся #2