feat(alerts): entregar alertas e resumos pelo Telegram (#145)

[BryanPinheiro77]

Objetivo

Falhas entre RabbitMQ, API e Telegram podiam perder resumos ou marcar uma reserva como entrega concluída. A mudança persiste as notificações antes de publicar, exige uma reserva transacional com token e registra a confirmação de entrega, permitindo recuperação de falhas conhecidas e controle individual pelo usuário.

Alterações realizadas

• Outbox PostgreSQL e migration V15, IDs opacos por usuário/regra/período e publicação em lotes.
• Reserva exclusiva, ACK idempotente, retry de rejeições explícitas e estado UNKNOWN para respostas ambíguas.
• Recuperação do último período fechado, preferências individuais e comandos /alertas.
• Testes de persistência, entrega, contratos HTTP/RabbitMQ, preferências e falhas; documentação de retenção e limites.

Tipo de mudança

• Feature
• Bugfix
• Refatoração
• Testes
• Documentação
• Configuração/infra

Checklist de qualidade

• O PR tem escopo pequeno e claro
• Executei ./mvnw clean verify
• Os testes automatizados passaram
• Rodei análise local no SonarQube quando houve alteração relevante
• O Quality Gate continua aprovado quando houve análise SonarQube
• Não introduzi novas issues críticas de Security ou Reliability
• Mantive ou aumentei a cobertura de New Code quando houve código novo
• Atualizei o CHANGELOG.md quando necessário
• Atualizei o README.md ou documentação quando necessário
• Verifiquei que não foram adicionados tokens, senhas ou secrets

Evidências

API e bot: ./mvnw -q clean verify passaram. Em macOS, Mockito foi pré-carregado como javaagent somente no comando local para evitar a limitação de auto-attach; nenhuma configuração de ambiente foi versionada.

git diff --check passou. O CI deve validar o novo HEAD antes do merge.

Exemplos:

• Resultado do ./mvnw clean verify
• Print do SonarQube
• Print da funcionalidade testada
• Link da issue relacionada

Testes realizados

• ./mvnw clean verify
• Testes unitários específicos
• Teste manual
• Análise SonarQube local
• Não se aplica

Issue relacionada

Relacionado a #145 e #119. Base final: develop.

Limites de entrega

Telegram não suporta chave de idempotência no envio. Timeout, falha definitiva do ACK ou reserva expirada ficam UNKNOWN, sem reenvio automático, para evitar duplicidade; exigem reconciliação operacional. Não há garantia absoluta de exactly-once. Rejeições explícitas 4xx permitem até cinco tentativas. Recuperação de resumos considera o último período fechado, sem retrospectiva ilimitada.

A migration é aditiva, não altera migrations anteriores e não exige nova credencial em produção. Preferências individuais existentes começam ativadas; podem ser desativadas via /alertas desligar.