[hbgit]

Closes #80

Resumo

Quando o MQTT do aparelho do ACS não está conectado, o app passa a consultar por HTTPS os alertas abertos da microárea e os põe na mesma fila de priorização, sem duplicar o que o MQTT entregar depois e sem nunca desfazer um ACK (PRD R2, INV-03). Antes, com o broker inalcançável, o ACS não tinha como receber alerta nenhum. Plano: docs/superpowers/plans/2026-10-17-issue-80-reserva-http-alertas.md.

Backend

• alerts.openForMicroArea(accessToken) → List<AcsOpenAlert>: só ACS com microárea, que vem do token (INV-01). Devolve pending/escalated e depois acknowledged (concluídos fora), cada grupo do mais antigo ao mais novo, teto de 200 que corta os mais antigos — nunca o pendente mais novo. Campos = envelope MQTT + status, acknowledgedAt, escalated; sem escalatedBy/escalationReason.
• Sem linha de auditoria de leitura por consulta (D2): o app repete a cada 30 s com o broker fora, e o mesmo conteúdo chega pelo MQTT sem auditoria. ACK e conclusão seguem auditados.
• Sem migração.

App do ACS

• AlertHttpFallback + AlertQueue.mergeFromServer: nunca remove cartão, ignora outra microárea, só ganha ACK/reforço (um ACK feito em outro aparelho promove o cartão), nunca desfaz; só notifica quando algo muda.
• AcsHomeShell: consulta ao abrir o painel, ao voltar ao primeiro plano e no instante em que a reserva arma; a cada 30 s só enquanto o broker está fora e o app em primeiro plano; uma consulta por vez, resposta tardia descartada no dispose. Linha alert_fallback_status no painel ("Recebendo alertas pelo servidor a cada 30 s. Última consulta às HH:MM.").
• Correção achada na revisão final: com autoReconnect, o mqtt_client 10.5.1 não chama onDisconnected quando o broker cai depois de conectar — o painel seguia "em linha" (defeito anterior a esta issue) e a reserva nunca ligaria. MqttSecureClient agora trata onAutoReconnect como queda e usa disconnectOnNoResponsePeriod = 10 contra conexão meio aberta (test/mqtt_drop_after_connect_test.dart, broker falso em TCP real).

Testes

• Backend: dart test -j 1 1418/1418 (test/integration/acs_open_alerts_test.dart, grupo openForAcs (#80) em red_alert_service_test.dart).
• ACS: flutter test 628/628 (alert_queue_merge_test.dart, alert_http_fallback_test.dart, alert_http_fallback_shell_test.dart, mqtt_drop_after_connect_test.dart); flutter analyze limpo; ci_invariants.sh ok.
• Emulador (emulator-5554, banco de teste): scripts/qa/acs_alert_fallback_e2e.sh — broker fora do alcance do aparelho, alerta inserido por SQL sem alert_outbox, intervalo de produção de 30 s: o cartão apareceu sem toque em 29 633 ms, foi confirmado pela tela e seguiu único e confirmado depois de mais um tique; no banco, acknowledged, 1 linha acknowledged, 0 leituras auditadas, 0 linhas no outbox. Log em docs/superpowers/plans/2026-10-17-issue-80-e2e.log. Regressão do MQTT real: integration_test/red_alert_cycle_test.dart 7/7 e e2e.sh --emulator verde.

Em aberto (registrado no PROGRESS.md)

• Sem consulta com o app em segundo plano (WorkManager fora de spec/stack.md); sem som/vibração/notificação do SO.
• Alerta concluído em outro aparelho do mesmo ACS segue pendente neste até sair do app.
• D2 (sem auditoria de leitura) precisa de confirmação do encarregado de dados.