Tira as integrações com o Telegram da requisição do usuário

[Hirley]

Fecha a #78.

Duas telas falavam com a API do Telegram dentro do ciclo de request/response — o envio do relatório semanal (que ainda gerava o PDF antes) e a redefinição de senha por Telegram. A latência das duas dependia de um serviço de terceiro, e com RAILS_MAX_THREADS no default de 5 poucos pedidos presos bastavam para degradar a aplicação inteira, inclusive telas sem relação nenhuma com Telegram.

As duas passaram a enfileirar (RelatorioSemanalTelegramJob, TelegramPasswordResetJob) e responder na hora. Isso só faz sentido depois da #77: com a fila em memória, o que saía da requisição virava o que se perdia no restart seguinte.

Decisões

A checagem "dá pra enviar?" ficou na tela, não no job. Os dois motivos previsíveis de falha (servidor sem TELEGRAM_BOT_TOKEN, usuário sem Chat ID) são exatamente o que o alerta da tela explica, e nenhum precisa tocar a rede — então o aviso continua imediato. Virou TelegramNotifier#pode_enviar_para?, que de quebra passou a ser a guarda única dos três métodos de envio, no lugar da mesma condição repetida três vezes.

Enfileirar reforça a resposta genérica da redefinição de senha, não a enfraquece. Antes, o e-mail cadastrado com Chat ID esperava o Telegram responder e o e-mail desconhecido voltava na hora: a mensagem era a mesma nos dois casos, mas o cronômetro entregava a diferença que ela tenta esconder. Agora os dois caminhos fazem um SELECT, e um deles um INSERT na fila.

Descartado: enfileirar sempre, passando o e-mail digitado para o job (o que deixaria a resposta rigorosamente constante). Guardaria e-mail arbitrário de visitante anônimo na tabela de jobs e deixaria um formulário público encher a fila — e o throttle por IP/e-mail já é o que barra esse uso.

Relatorios::GerarPdfSemanal nasceu porque os dois caminhos que geram o PDF de verdade precisam fazer exatamente a mesma coisa: montar os dados, anunciar relatorio_gerado e renderizar. Repetir a montagem do payload nos dois era garantia de eles divergirem no primeiro campo novo. O download (GET /relatorios/semanal.pdf) continua síncrono de propósito: ali o PDF é a resposta, não há como devolvê-lo depois.

O que se perde

Uma falha no envio em si — Telegram fora do ar, timeout — não aparece mais na tela: quem pediu vê "chega em instantes" e nada chega. Fica registrada no log do job em nível warn. Trazer isso de volta exigiria persistir o resultado de cada envio e uma tela para consultar o status; é desproporcional para o caso raro, e a alternativa era continuar prendendo um worker do Puma por causa dele.

Consequência operacional que também entrou no README: sem o processo bin/jobs de pé, essas duas telas respondem normalmente e nada é entregue — os jobs se acumulam em solid_queue_jobs até alguém subir o worker.

Verificação

No container (ruby:4.0.6-slim + postgres:16-alpine, espelhando o ci.yml):

• RuboCop — 110 arquivos, 0 ofensas;
• bin/rails zeitwerk:check — All is good!;
• RSpec — 384 exemplos, 0 falhas (eram 375).

Não verificado no navegador. Nada de JS, CSS, HAML ou CSP mudou — só o texto de dois flashes, que os request specs conferem. Verificar a tela de ponta a ponta exigiria login, que não faço.

Vai junto um commit separado corrigindo o cabeçalho do WebhookDeliveryJob, que ainda descrevia o adapter :async e chamava a fila persistente de "assunto de outra issue" — a issue em questão é a #77, já entregue.