ingest: закрыты мелочи приёма — вырожденное имя, контракт Result, корреляция add

- имя раздачи нормализуется на границе разбора: вырожденное `-`
  (metainfo.NoName) даёт пустое имя, пробельное схлопывается — сентинел больше
  не доходит ни до контекста распознавания, ни до source_ref, ни до подсказки
  вывода имени
- контракт «на любом пути ошибки приёма результат нулевой» объявлен в ingest и
  удерживается структурно; три транспорта перестали обещать идентификатор,
  которого нет, и коррелируют отказ по request_id
- scoped-логгер загрузки ставится до вызова внешнего сервиса в семи командах
  воркера — записи об отказе qBittorrent и метабаз получили download_id
  и infohash; граница разбора bencode записана в docs/research

docs/conventions/errors.md

@@ -66,7 +66,15 @@ jellybit — **приложение, а не библиотека**: внешн
   - **+ корреляционный ключ** для владельца — `download_id` (если операция
     к загрузке) либо `request_id`, чтобы по нему найти полную ошибку в логах.
     Пример: «При обработке загрузки произошла ошибка, download_id=12345», а
-    не «произошла ошибка» и не сырой текст;
+    не «произошла ошибка» и не сырой текст.
+    **Ключ есть не у всякого транспорта, и это называется вслух.** `request_id`
+    — понятие HTTP-границы (chi `RequestID`); у Telegram и CLI его нет. Если
+    операция ещё не завела загрузку (отказ приёма), у такого транспорта ключа
+    нет вовсе — тогда сообщение остаётся без якоря, а диагностика ищется по
+    записи доменной границы (`capability`, `infohash`). Заводить транспорту
+    собственный идентификатор запроса ради ключа — решение уровня спеки, а не
+    умолчание: второй канал корреляции рядом с существующим дороже, чем
+    отсутствие ключа;
   - **маппинг доменной ошибки → статус/сообщение** (в jellybit —
     `httpapi.classifyErr`, единая точка для REST и веб-UI):