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

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

docs/security.md

@@ -15,11 +15,10 @@
 записи, а чужая отвечает «не найдено». Целевому периметру недостаёт теперь второго уровня
 доступа — страницы расхода для владельца сервиса.
 
-Записи, принятые ботом, владельца не имеют и по API не достаются никому: связи
-чата с учётной записью приложения нет, её заводит `telegram-account-link`.
-
-Разграничение доступа в Telegram осталось прежним — белым списком, и с учётной
-записью приложения он не связан.
+Ничьих записей у сервиса больше не бывает: колонка владельца пустого значения
+не принимает, и держит это схема хранилища. Прежде такие записи заводил вход
+Telegram — связи чата с учётной записью сервис не вёл, — и 2026-08-14 вход убран
+вместе с этим исключением.
 
 **Целевой периметр шире сегодняшнего не только входом.** Содержимое записи
 начинает уходить на три новые стороны — языковой модели, в канал уведомлений и
@@ -59,9 +58,7 @@
 | --- | --- | --- |
 | Аудиофайл и его имя | `POST /api/audio`, multipart-поле `audio` | Любой вошедший через OIDC; без сессии — `401` до чтения тела |
 | Идентификатор задачи | `GET /api/status/:id` | Любой вошедший через OIDC; без сессии — `401`, одинаковый для заведённой и незаведённой задачи |
-| Голосовое, аудио, документ | Telegram, длинный опрос | Любой пользователь Telegram; обрабатывается только из белого списка |
-| Имя файла в Telegram | Поле `file_path` ответа Bot API | Telegram, а через него — отправитель |
-| Содержимое аудио | Файл, скармливаемый `ffmpeg` и `ffprobe` | Отправитель по любому из каналов |
+| Содержимое аудио | Файл, скармливаемый `ffmpeg` и `ffprobe` | Отправитель |
 | Текст расшифровки | Поток gRPC от SpeechKit | Yandex, а через него — содержимое записи |
 
 Что добавится вместе с целевым периметром — каждый вход появляется своей
@@ -82,9 +79,10 @@
 
 ## Куда уходит содержимое записи
 
-Сегодня запись и её текст покидают наш сервер тремя путями: файл уезжает в
-Yandex Object Storage, оттуда его читает SpeechKit, а текст возвращается в
-Telegram отправителю.
+Сегодня запись покидает наш сервер двумя путями: файл уезжает в Yandex Object
+Storage, оттуда его читает SpeechKit. Третий путь — ответ в Telegram — исчез
+2026-08-14 вместе с убранным входом: текст теперь достаётся только по опросу
+готовности и в панели владельца.
 
 Целевой периметр добавляет три пути, каждый — своей задачей:
 
@@ -156,10 +154,6 @@ Telegram отправителю.
 
 ## Что разграничивает доступ
 
-- **Telegram** — белый список `[server] users_while_list`. Сверяется со строкой
-  автора сообщения (`update.Message.From.String()`, то есть `@username` либо имя
-  с фамилией), а не с числовым идентификатором. Имя пользователя Telegram
-  меняется владельцем в любой момент: список привязан к изменяемому значению.
 - **HTTP API** — сессия, заведённая входом через OIDC у Authelia. Предъявляется
   кукой `transcriber_session`, обесценивается выходом, срок жизни назначен числом
   ([database.md](database.md), «Настройки с числовым значением»).
@@ -203,9 +197,6 @@ Telegram отправителю.
 | Личный токен | Права своего владельца программе, без браузерной сессии | `api-tokens` |
 | Признак владельца сервиса | Страницу расхода и сводку по всем пользователям | `admin-stats-screen` |
 
-Белый список Telegram при этом перестаёт быть отдельным механизмом: право
-писать боту выводится из учётной записи (`telegram-account-link`).
-
 Признак владельца сервиса — **второй уровень доступа**, которого в сегодняшней
 модели нет вовсе: до него всё разграничение сводилось к «свой или чужой».
 Откуда он берётся — из группы OIDC или из конфигурации — не решено
@@ -229,10 +220,10 @@ Telegram отправителю.
    `record_events` (журнал событий, содержимого не несёт) и `topics` (словарь
    тем человека). Всякая новая коллекция, куда содержимое переезжает, закрывается
    наравне с записью — норму держит спека `storage`.
-2. **Токен бота Telegram.** Даёт полный доступ к боту и к перепискам с ним.
-3. **Ключи Yandex Cloud** — `speech_kit_api_key` и пара ключей Object Storage.
+2. **Ключи Yandex Cloud** — `speech_kit_api_key` и пара ключей Object Storage.
    Утечка оплачивается деньгами и доступом к бакету.
-4. **Белый список пользователей** — сам по себе перечень имён.
+3. **Секрет клиента OIDC** — вместе с адресами провайдера открывает вход в
+   приложение от чужого имени.
 
 Всё перечисленное лежит в `config.toml`. Файл в `.gitignore`, на сервер его
 кладёт Ansible; `gitleaks` на pre-commit смотрит только индекс коммита.
@@ -288,30 +279,14 @@ Telegram отправителю.
 приведения хвост читал бы кто угодно из интернета, а множеством значений метки
 распоряжался бы анонимный отправитель.
 
-Приём из Telegram имени, данного человеком, до сервиса не доводит: оттуда
-приходит путь, выданный самим Telegram. Настоящее имя документа дальше проверки
-типа файла не идёт.
+Два пути утечки токена бота — адрес Bot API в отказе транспорта и отказ сборки
+клиента — закрыты задачами `no-user-filename-in-log` и
+`local-run-without-telegram-token` 2026-08-13 и потеряли предмет 2026-08-14
+вместе с убранным входом: ни клиента, ни токена у сервиса больше нет. Разбор
+случая остался в [review.md](review.md) — он про класс, а не про Telegram.
 
-Токен бота стоит в пути **каждого** обращения к Bot API (`bot<TOKEN>/getFile`,
-`…/sendMessage`, `…/getMe`, `…/getUpdates`) и в ссылке на скачивание
-(`file.Link(token)`). Сами адреса нигде не логируются, но до 2026-08-13 их
-уносил **отказ транспорта**: `*url.Error` встраивает адрес целиком, а отказы
-скачивания и отправки пишутся в журнал. Теперь адрес на границе клиента снимает
-свой `Do` — `internal/adapter/telegram`, `NewBot`: он чистит отказ, а
-подменённый логгер библиотеки вычищает токен из строк длинного опроса, которые
-она печатает сама. Транспорт бота токена больше не получает вовсе: клиента ему
-отдают готовым. Правило — [conventions/logging.md](conventions/logging.md),
-случай — [review.md](review.md), оракул — `internal/adapter/telegram/bot_test.go`.
-
-Ещё один путь закрыт задачей `local-run-without-telegram-token` 2026-08-13, и до
-неё он был открыт: токен, не разбирающийся как часть адреса (перенос строки из
-шаблона выкладки, невычищенная `%`-последовательность), роняет сборку клиента
-**раньше** обращения к нему — то есть мимо чистки на границе клиента. Отказ
-конструктора теперь чистится отдельно. Нашло это ревью кода тремя проходами
-независимо; оракул — там же, в `bot_test.go`.
-
-Третий путь закрыт задачей `telegram-enabled-flag` 2026-08-13, и он **шире
-токена бота**: до неё утечь мог любой секрет конфига. Отказ разбора файла
+Путь, который остался, закрыт задачей `telegram-enabled-flag` 2026-08-13, и он
+**шире всякого одного ключа**: до неё утечь мог любой секрет конфига. Отказ разбора файла
 настроек пересказывался как есть, а библиотека разбора собирает текст отказа из
 разбираемого куска — `toml.ParseError` кладёт в сообщение само значение. Строка
 секретного ключа с оборванной кавычкой — типовая поломка криво собранного