удалён вход Telegram, владелец записи стал обязателен в схеме

- убраны клиент бота, транспорт обновлений, отправитель сообщений, сборка
  входа при старте, секция настроек и зависимость go-telegram-bot-api; из
  конвейера ушла доставка ответа отправителю — исход виден опросом готовности.
  Колонки адресата и значение источника остались в схеме: применённые шаги не
  переписываются
- шаг 202608140003 запрещает пустого владельца у аудиозаписи и у файла;
  существующие строки он не проверяет, и это принято сознательно — искать их
  надо запросом до выкладки
- ревью нашло два пред-существующих дефекта, оба закрыты: пустой второй ответ
  распознавателя стирал сохранённую расшифровку, а пустая расшифровка перестала
  быть заметной вместе с убранной доставкой. Попутно поднят golang.org/x/image
  до v0.45.0 — красный шаг vulns, воспроизводился и на чистом master

openspec/specs/storage/spec.md

@@ -17,8 +17,8 @@
 ### Requirement: Сервис поднимается на чистом каталоге данных
 
 Сервис SHALL приводить хранилище в рабочий вид сам: на пустом каталоге данных он
-MUST завести свою схему и принимать записи обоими входами без единого ручного
-шага до первого запуска.
+MUST завести свою схему и принимать записи своим входом — приёмом по HTTP — без
+единого ручного шага до первого запуска.
 
 Прежние данные не переносятся. Каталог, оставшийся от прежней раскладки, MUST не
 читаться и не считаться источником: сервис начинает с чистого листа, и это
@@ -267,14 +267,14 @@ MUST завести свою схему и принимать записи об
 печатается оно в журнал контейнера, откуда строку не убрать: бессрочное отдало бы
 панель всякому читателю логов навсегда.
 
-Пока владелец пароля не задал, сервис MUST работать обоими входами: панель без
-владельца не мешает принимать записи.
+Пока владелец пароля не задал, сервис MUST принимать записи: панель без владельца
+приёму не мешает.
 
 #### Scenario: Владелец пароля ещё не задал
 
 - **GIVEN** каталог данных пуст и владелец панели не заведён
 - **WHEN** сервис запускается
-- **THEN** он принимает записи обоими входами
+- **THEN** он принимает записи
 - **AND** ни один ключ конфигурации не несёт пароля от панели
 
 #### Scenario: Владелец заведён, приглашение больше не печатается
@@ -289,10 +289,13 @@ MUST завести свою схему и принимать записи об
 учётной записью, — и эта колонка MUST не иметь умолчания: запись, чей владелец
 не назван, не достаётся никому по недосмотру схемы.
 
-Колонка MUST допускать пустое значение, и это решение с названной ценой: записи,
-принятые ботом, владельца не имеют, потому что связи чата Telegram с учётной
-записью сервис не ведёт. Обязательность для приёма по HTTP держит сама
-capability `intake`, а не схема.
+Колонка MUST не допускать пустого значения. Прежде допускала, и цену платили за
+записи, принятые ботом: связи чата с учётной записью сервис не вёл. С убранным
+входом заводить ничью запись стало некому, и обязательность переезжает из одного
+лишь приёма в схему — туда, где её держит хранилище, а не договорённость. Разница
+не косметическая: пока обязательность жила в приёме, ничью запись заводили руками
+в панели, и она уходила в конвейер, стоила денег на распознавание и не доставалась
+потом никому.
 
 Владелец MUST не назначаться и не меняться конвейером.
 
@@ -301,6 +304,14 @@ capability `intake`, а не схема.
 - **WHEN** сервис поднимается на чистом каталоге данных
 - **THEN** у аудиозаписи есть колонка владельца
 - **AND** умолчания у неё нет
+- **AND** пустого значения она не принимает
+
+#### Scenario: Запись без владельца не сохраняется
+
+- **GIVEN** сервис поднят
+- **WHEN** аудиозапись пытаются сохранить с пустым владельцем — приёмом,
+  конвейером или руками в панели
+- **THEN** хранилище её не сохраняет
 
 #### Scenario: Конвейер владельца не назначает
 
@@ -313,9 +324,16 @@ capability `intake`, а не схема.
 Хранилище SHALL держать владельца и у файла записи — той же связью с учётной
 записью, — и правило просмотра файлов MUST пускать к файлу только его владельца.
 
-Владелец файла MUST назначаться там же, где владелец записи, — при приёме, из
-предъявленной сессии, — и MUST оставаться пустым у файлов, заведённых конвейером
-для записи без владельца.
+Владелец файла MUST назначаться при приёме, из предъявленной сессии, а колонка
+файла MUST не допускать пустого значения наравне с колонкой записи. Прежде пустое
+значение оставалось у файлов, заведённых конвейером для записи без владельца;
+таких записей больше не заводится, и разное правило у записи и у её файла
+читалось бы как недосмотр.
+
+Файл, заведённый шагом конвейера, — приведённую копию заводит именно он —
+MUST получать владельца своей записи. Иного источника владельца у файла нет, и
+шаг, оставивший его пустым, упрётся в отказ сохранения: запись накопит отказы и
+остановится признаком на первом же приведении.
 
 Ссылки на файлы у записи две — на принятую копию и на приведённую, — и обе живут
 до конца, но владелец файла MUST по-прежнему лежать своей колонкой, а не
@@ -340,12 +358,18 @@ capability `intake`, а не схема.
 - **WHEN** он идёт по ссылке на файл своей записи со своим токеном
 - **THEN** содержимое отдаётся
 
-#### Scenario: Файл записи из Telegram не отдаётся по API
+#### Scenario: Файл без владельца не сохраняется
 
-- **GIVEN** запись принята ботом, и владельца у неё нет
-- **WHEN** вошедший человек идёт по ссылке на её файл со своим токеном
-- **THEN** содержимого он не получает
+- **GIVEN** сервис поднят
+- **WHEN** файл записи пытаются сохранить с пустым владельцем
+- **THEN** хранилище его не сохраняет
 
+#### Scenario: Приведённая копия получает владельца записи
+
+- **GIVEN** запись с владельцем дошла до приведения
+- **WHEN** шаг заводит приведённую копию файла
+- **THEN** владельцем копии стоит владелец записи
+- **AND** шаг завершается без отказа
 ### Requirement: Учётная запись с записями не удаляется
 
 Хранилище SHALL отвергать удаление учётной записи, у которой остались
@@ -551,3 +575,31 @@ MUST быть помечено защищённым.
 - **WHEN** записи назначают шестую тему
 - **THEN** назначение не проходит
 
+### Requirement: Пустой результат не кладётся поверх сохранённого
+
+Хранилище SHALL не заменять сохранённое содержимое приложения записи — текст и
+структуру реплик — пустым. Замена пустым MUST оставлять прежнее значение и
+считаться сделанной работой, а не отказом.
+
+Требование стоит на повторном опросе одной и той же операции распознавания.
+Повтор — обычное дело: держатель захвата умер, сохранение рубежа отказало,
+человек снял признак остановки в панели. Провайдер при этом вправе ответить
+пустым потоком, отказом это не считается, и безусловная замена стирала бы
+расшифровку живого человека — без следа и без возврата, потому что сервис
+объявлен архивом и удаления по требованию не знает.
+
+Та же защита MUST стоять у сырого ответа провайдера: разное правило у двух
+хранителей одного результата читается как недосмотр, и один из них молча теряет
+то, ради чего второй заведён.
+
+Норма записана со стороны **хранилища**, а не шага: шагов, кладущих текст,
+больше одного, и правило, записанное у одного из них, у остальных читалось бы
+как снятое.
+
+#### Scenario: Пустой второй ответ не стирает расшифровку
+
+- **GIVEN** расшифровка записи сохранена
+- **WHEN** ту же операцию опрашивают снова, и провайдер отвечает пустым
+- **THEN** сохранённая расшифровка остаётся прежней
+- **AND** шаг завершается без отказа
+