Идентичность на 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>

docs/conventions/database.md

@@ -0,0 +1,47 @@
+# Конвенция: база данных и идентификаторы
+
+Как мы устраиваем таблицы и ключи в SQLite. Актуальная схема —
+[../specs/database.md](../specs/database.md); обоснование выбора ULID —
+`openspec/changes/ulid-identity/design.md` (после архивации — в истории git).
+
+## Первичные ключи — ULID, не автоинкремент
+
+- **PK сущности — TEXT ULID** (26 символов Crockford base32), генерируется
+  **приложением** в момент создания записи. `INTEGER PRIMARY KEY
+  AUTOINCREMENT` в новых таблицах не используем.
+- Почему ULID: сортируем по времени создания (`ORDER BY id` = хронология),
+  компактен и удобен в URL/логах (без дефисов — grep и двойной клик берут id
+  целиком), глобально уникален across таблиц — поиск по голому id находит
+  все записи сущности в логах.
+- **Единственная точка генерации и разбора — `internal/ident`**:
+  `ident.NewID()` при создании (в Create-методах `store`), `ident.Parse()`
+  на входных границах. Никаких самодельных генераторов.
+
+## Канонический вид — lowercase
+
+- Генерим и храним id в **нижнем регистре**. Сравнение строк в SQLite
+  побайтовое, поэтому любой внешний id (URL, форма, callback-data)
+  ОБЯЗАТЕЛЬНО проходит `ident.Parse` до запроса к БД — он валидирует формат
+  и нормализует регистр (base32 ULID case-insensitive при декодировании).
+- Синтаксически невалидный id трактуем как несуществующую сущность (404),
+  без похода в БД.
+
+## Естественные и составные ключи — для деталей
+
+- У таблиц-деталей/связей допустим естественный или составной ключ вместо
+  ULID, когда он есть по природе данных: `download_infohash` — PK
+  `(infohash, download_id)`, `override` — `UNIQUE(download_id, field)`.
+  Отдельный ULID там — мёртвый вес.
+- Прочие генерируемые идентификаторы (например, `apply_batch_id`) — тоже
+  через `ident.NewID()`: единый формат, сортируемость, корреляция в логах.
+
+## Прочее
+
+- Enum-поля (`state`, `kind`, …) — обычный `TEXT` без `CHECK`; допустимые
+  значения держит код (`internal/store`).
+- Временные метки — `TEXT DEFAULT (datetime('now'))` (UTC), формат
+  `store.ParseTime`/`FormatTime`.
+- Миграции — goose (`internal/store/migrations`): SQL-файлы для DDL;
+  Go-миграции (`goose.AddMigrationContext`) — когда нужен код (генерация
+  id, backfill). При изменении структуры обновляем ER-схему
+  [../specs/database.md](../specs/database.md) в том же change.