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

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

docs/database.md

@@ -47,7 +47,7 @@ CGO сборке не нужен.
 | --- | --- | --- |
 | `id` | TEXT PK | Идентификатор записи, выдаёт хранилище |
 | `file` | file | Сам файл |
-| `owner` | relation → `users` | Владелец файла; пусто у файлов записи, принятой ботом |
+| `owner` | relation → `users` | Владелец файла; пустого значения не принимает |
 | `location` | select | `local` или `s3` |
 | `object_key` | TEXT | Ключ объекта; заведён прежним шагом и новым путём не заполняется |
 | `size` | INTEGER | Размер в байтах |
@@ -66,8 +66,8 @@ capability, и третий смысл развёл бы одно слово п
 | Поле | Тип | Что |
 | --- | --- | --- |
 | `id` | TEXT PK | Идентификатор записи, выдаёт хранилище |
-| `owner` | relation → `users` | Владелец записи; пусто у записей, принятых ботом |
-| `source` | select | `api`, `telegram`, `unknown` |
+| `owner` | relation → `users` | Владелец записи; пустого значения не принимает |
+| `source` | select | `api`, `unknown`; значение `telegram` осталось историческим — вход убран, новых записей с ним не появляется |
 | `title`, `brief` | TEXT | Заголовок и краткое описание: читаются вместе со списком |
 | `state` | select | Рубеж: `uploaded`, `normalized`, `submitted`, `transcribed`, `done`; перечень закрыт схемой |
 | `state_entered_at` | DATETIME | Время входа в рубеж — сторож застревания |
@@ -84,8 +84,8 @@ capability, и третий смысл развёл бы одно слово п
 | `structure` | relation → `structures` | Структура реплик |
 | `recognition` | relation → `recognitions` | Попытка распознавания |
 | `topics` | relation → `topics`, до 5 | Темы записи |
-| `tg_chat_id` | INTEGER | Куда отправить результат |
-| `tg_reply_message_id` | INTEGER | С каким сообщением связать |
+| `tg_chat_id` | INTEGER | Адресат ответа у записи убранного входа; кодом не читается |
+| `tg_reply_message_id` | INTEGER | Ответное сообщение у неё же; кодом не читается |
 | `created`, `updated` | DATETIME | Проставляет хранилище |
 
 Индекс один — по паре «рубеж и признак остановки»: выборка захвата идёт по ним,
@@ -188,10 +188,15 @@ capability, и третий смысл развёл бы одно слово п
 висела бы в панели вторым домом для понятия, которого больше нет.
 
 **Владелец записи** заведён шагом `202608140001` — связью с коллекцией `users` в
-обеих таблицах. Пустое значение допустимо, и это решение с ценой: записи,
-принятые ботом, владельца не имеют вовсе, потому что связи чата Telegram с
-учётной записью сервис не ведёт. Обязательность для приёма по HTTP держит поэтому
-сам приём, а не схема.
+обеих таблицах, — и шагом `202608140003` пустого значения больше не принимает.
+Прежде принимал, и цену за это платили записи входа Telegram: связи чата с
+учётной записью сервис не вёл. Вход убран 2026-08-14, ничью запись заводить стало
+некому, и обязательность переехала из приёма в схему — туда, где её держит
+хранилище, а не договорённость.
+
+**Колонки `tg_chat_id` и `tg_reply_message_id`** остались от убранного входа и
+кодом больше не читаются. Из схемы они не убираются: заводили их применённые
+шаги `202608110001` и `202608140002`, а применённый шаг не переписывается.
 
 Выборка по владельцу сужает **чтение записи**: чужая, ничья и несуществующая
 дают один и тот же отказ. Выборку воркера владелец не сужает — конвейер
@@ -288,11 +293,8 @@ capability, и третий смысл развёл бы одно слово п
 | Задержка перед первой проверкой операции | 10 секунд | `service/transcribe.go` | как было |
 | Задержка между проверками операции | 5 секунд | там же | как было |
 | Пауза воркера между прогонами | 1 секунда | `controller/worker/worker.go` | как было |
-| Предел длины сообщения Telegram | 4000 символов | `adapter/telegram/sender.go` | предел Telegram |
 | Таймаут мягкой остановки | 5 секунд | конфиг, `[server] shutdown_timeout` | — |
 | Таймаут жёсткой остановки | 20 секунд | конфиг, `[server] force_shutdown_timeout` | — |
-| Таймаут обновлений Telegram | 10 секунд | конфиг, `[telegram] update_timeout` | — |
-| Срок ожидания Telegram при сборке клиента | 10 секунд | `adapter/telegram.ProbeTimeout` | решение, не замер: одно обращение за `getMe` укладывается в доли секунды, дольше Telegram считается недоступным и сервис поднимается без него. Длинный опрос этим сроком не ограничен — клиент подменяется сразу после сборки |
 | Качество кодирования vorbis | `-q:a 4` | `adapter/converter/ffmpeg/ffmpeg.go` | — |
 | Жизнь приглашения завести владельца панели | 30 минут | умолчание PocketBase | — |
 | Потолок размера одной записи | 8 ГиБ | `entity.MaxRecordSize` | расчётный потолок в шесть часов с запасом на видео |
@@ -320,4 +322,4 @@ capability, и третий смысл развёл бы одно слово п
 Чего среди настроек **нет**: режим журналирования, таймаут занятости и размер
 пула соединений задаёт хранилище своими умолчаниями, а не мы; срока хранения
 файлов и объектов нет вовсе. Таймаутов у
-обращений к Telegram, S3 и SpeechKit тоже нет — ни одного.
+обращений к S3 и SpeechKit тоже нет — ни одного.