telegram: сервис поднимается без бота и работает одним входом

- Клиент бота собирается один раз и достаётся отправителю и транспорту;
  разрез прошёл по «ответил ли Telegram»: ответ «такого бота нет» роняет
  старт, недоступность даёт подъём без Telegram (ADR-2026-08-13). Ожидание
  при сборке ограничено сроком — иначе молчащий Telegram вешал подъём.
- Недоставленный ответ не роняет шаг: пишется с job_id и считается метрикой,
  уровень по причине — WARN для неподнятого входа, ERROR для неназванного
  адресата. Заведены transcriber_intake_up и transcriber_undelivered_reply_count.
- Закрыта утечка токена в журнал: отказ разбора адреса рождается раньше
  обращения к клиенту, то есть мимо чистки на его границе.

openspec/changes/archive/2026-08-13-start-without-telegram-token/specs/intake/spec.md

@@ -0,0 +1,90 @@
+## Purpose
+
+Приём записи и опрос готовности задачи расшифровки: что считается принятой
+записью, что уезжает в ответ и что происходит, когда запись не удалось
+прочитать. Плюс наличие входов: с каким из них сервис вправе подняться.
+
+Приём по существу описан пока **только для HTTP** — того, что нормируют
+проверки. Про вход Telegram нормировано одно: настроен он или нет и что из этого
+следует для подъёма. Кто допущен к боту и как забирается присланная им запись,
+требованиями по-прежнему не описано — требование, написанное без проверки, это
+предположение, а не норма. Первая задача, которая трогает поведение приёма из
+Telegram, дописывает его сюда.
+
+## ADDED Requirements
+
+### Requirement: Недоступный или незаданный вход Telegram не мешает подъёму
+
+Сервис SHALL подниматься, когда вход Telegram поднять не удалось, и MUST
+продолжать работу оставшимся входом: приём по HTTP, опрос готовности и конвейер
+расшифровки работают в полном объёме. Неподнятый вход MUST быть назван в журнале
+**ровно одной** записью уровня `WARN` при старте — с причиной и без значения
+токена.
+
+Исключение одно, и оно проходит по тому, **ответил ли Telegram**. Ответ «такого
+бота нет» — ошибка настройки: бот по этому токену не появится ни от ожидания, ни
+от повтора, и старт MUST кончаться отказом. Сервис, молча потерявший бота после
+опечатки в токене, перестаёт отвечать своим отправителям, и узнать об этом было
+бы неоткуда.
+
+Всё прочее — недоступность: сеть, DNS, авария Bot API, истёкший срок ожидания.
+Она MUST не влиять на подъём. Основной вход сервиса — не Telegram, и класть его
+целиком из-за чужой аварии нельзя: перезапуск в такую минуту оставил бы без
+работы и приём по HTTP, и панель, и конвейер, которому Telegram не нужен вовсе.
+
+Ожидание при сборке MUST быть ограничено сроком. Без него недоступность
+неотличима от подъёма: обращение к Telegram стоит на пути старта, и молчащий
+собеседник останавливал бы его бессрочно — без записи, без порта и без пробы
+здоровья.
+
+Требование нормирует **наличие входа**, а не приём из него.
+
+#### Scenario: Токен не задан
+
+- **GIVEN** в настройках сервиса токен бота пуст
+- **WHEN** сервис запускается
+- **THEN** он поднимается и принимает записи по HTTP
+- **AND** конвейер расшифровки работает
+- **AND** бот не заведён, а в журнале ровно одна запись уровня `WARN` о том, что
+  он не поднят и почему
+
+#### Scenario: Токен задан и годен
+
+- **GIVEN** в настройках сервиса стоит токен, по которому Telegram признаёт бота
+- **WHEN** сервис запускается
+- **THEN** он поднимается и работает обоими входами
+
+#### Scenario: Telegram не отвечает
+
+- **GIVEN** в настройках сервиса стоит непустой токен
+- **AND** Telegram недоступен либо не отвечает дольше отведённого срока
+- **WHEN** сервис запускается
+- **THEN** он поднимается и принимает записи по HTTP
+- **AND** бот не заведён, а в журнале запись уровня `WARN` с причиной
+- **AND** запись не несёт значения токена
+
+#### Scenario: Telegram ответил, что такого бота нет
+
+- **GIVEN** в настройках сервиса стоит непустой токен
+- **AND** Telegram отвечает отказом на этот токен
+- **WHEN** сервис запускается
+- **THEN** старт кончается отказом
+- **AND** ни журнал, ни текст отказа не несут значения токена
+
+### Requirement: Поднятые входы видны наблюдателю
+
+Сервис SHALL отдавать признак поднятости по каждому входу приёма отдельной
+метрикой. Признак MUST выставляться при сборке входа и MUST различать поднятый
+вход и неподнятый.
+
+Требование стоит на том, что иначе потерянный вход не виден ничем: проба
+здоровья отвечает «сервис работает» и при неподнятом боте, а запись журнала
+живёт до ротации и вопрос «работает ли вход сейчас» не отвечает. Метрика —
+единственный канал наблюдения, который у владельца автоматизирован.
+
+#### Scenario: Вход Telegram не поднят
+
+- **GIVEN** сервис поднялся без Telegram
+- **WHEN** наблюдатель читает метрики
+- **THEN** признак поднятости входа Telegram равен нулю
+- **AND** признак поднятости входа HTTP равен единице