tasks: очередь расставлена от базы к деталям

- порядок беклога и роадмапа назначен слоями: проверки, которым можно
  верить → долги входа → владелец записи и контракт API → конвейер под
  тестами → приложение и возможности поверх; у каждого движения записана
  причина;
- заведены восемь задач под пункты «Завершения», которых не закрывала ни
  одна запись, — цель any-audio-source была без задач вовсе;
- у четырёх задач сняты критерии, требовавшие того, что делает задача ниже
  по очереди; исправлены ссылки на несуществующий repo/sqlite и на
  отменённую разведку об очереди.

tasks/items/dedup-by-content-hash.md

@@ -1,7 +1,7 @@
 # ✨ Узнавать уже загруженный файл по хеш-сумме
 
 - **Тип:** feature
-- **Категория:** Очередь
+- **Категория:** Очередь — Дедупликация ищет совпадение в пределах пользователя — то есть после владельца записи, и экономит деньги с первого дня приложения.
 - **Зачем:** Один и тот же файл, отправленный дважды, распознаётся дважды и оплачивается дважды: приём не смотрит на содержимое вовсе.
 - **Теги:** goal:upload-reliability
 
@@ -38,4 +38,6 @@
 Владелец записи приходит из `record-ownership` — до неё дедупликация опирается
 на того владельца, который уже есть. Хеш-сумма считается на сервере: подсчёт на
 стороне приложения относится к `chunked-upload-choice`. Колонка добавляется во
-всех четырёх местах репозитория SQLite (инвариант `CLAUDE.md`).
+всех четырёх местах пакета хранилища `internal/adapter/repo/pocketbase` —
+`applyToRecord`, `recordToJob`, `acquireColumns`, `acquiredRow` с её `toJob`, —
+плюс шаг схемы (инвариант `CLAUDE.md`).