feat: Fase 9/10 — métricas, scripts operacionais, callback/wrap-up e aceite final

Fase 9 (segurança e produção):
- GET /api/metrics: endpoint Prometheus com métricas reais (chamadas,
  agentes, filas, CPS por campanha), protegido por permissão
- scripts/backup.sh, restore.sh, healthcheck.sh, install.sh, update.sh —
  testados contra o ambiente real (backup.sh e healthcheck.sh rodados de
  verdade; install.sh/update.sh validados por inspeção, ambiente atual já
  provisionado)
- POST /api/agent-console/dispose: aplica disposição de chamada de verdade
  (lacuna deixada aberta desde a Fase 6), com ações CALLBACK (agenda
  retorno) e DO_NOT_CALL (suprime automaticamente)
- apps/dialer-worker/src/callback-sweep.ts: reativa leads com callback
  vencido; GET /api/callbacks para consulta
- apps/dialer-worker/src/wrap-up-sweep.ts: transição automática
  WRAP_UP -> AVAILABLE + despausa real na fila do Asterisk. Exigiu corrigir
  main.ts para conectar ao AMI mesmo em DIALER_SIMULATION=true
  (DIALER_SIMULATION deve impedir só originação de chamada, não ações
  administrativas de fila)
- nftables revisado (sem alterações necessárias)
- Documentação completa: INSTALL, OPERATIONS, BACKUP_RESTORE, SECURITY,
  DATABASE, API, ASTERISK, OPENSIPS (não implementado, motivo
  documentado), TROUBLESHOOTING
- README.md e CHANGELOG.md reescritos

Fase 10 (testes e aceite):
- Quality gate completo executado: build/typecheck (7 workspaces), lint,
  46 testes unitários, docker compose config/ps, healthcheck — tudo verde
- Aceite de segurança (seção 92): 13 itens verificados ao vivo contra o
  sistema real, não só por inspeção de código
- Aceite Asterisk (seção 93): os 5 comandos executados e documentados,
  comunicação API->AMI->Asterisk validada
- docs/RELATORIO_FINAL.md: relatório final no formato da seção 96

Todos os fixtures de teste desta fase foram removidos/desativados ao
final. Credenciais de acesso entregues separadamente em CREDENCIAIS.txt
(fora do git, nunca versionado).

docs/OPENSIPS.md

@@ -0,0 +1,51 @@
+# B2BCall — OpenSIPS (não implementado nesta fase)
+
+A arquitetura alvo do projeto (agente.md seção 5) prevê OpenSIPS na frente
+do Asterisk:
+
+```text
+INTERNET → [OpenSIPS] → rede SIP privada → [Asterisk] → [B2BCall]
+```
+
+**Este componente não foi implantado neste ciclo.** O Asterisk hoje recebe
+tráfego SIP diretamente (protegido por nftables, sem IP público — ver
+`docs/ARCHITECTURE.md` §3.2). Isso é suficiente para o ambiente de
+laboratório atual (um servidor, troncos configurados diretamente no
+Asterisk), mas não entrega os benefícios que OpenSIPS traria:
+
+- Balanceamento entre múltiplas instâncias de Asterisk.
+- Roteamento/normalização de múltiplos troncos antes de chegar ao core de
+  telefonia.
+- Uma camada adicional de proteção SIP (rate limiting, topology hiding)
+  antes do Asterisk.
+
+## Por que não foi feito agora
+
+Motivo honesto: com um único servidor e um único Asterisk, OpenSIPS não
+resolve nenhum problema real deste ambiente — adicionaria complexidade
+operacional (mais um serviço com seu próprio config/estado/observabilidade)
+sem benefício imediato. A decisão de projeto (agente.md seções 71/72) é não
+construir infraestrutura para um cenário hipotético que ainda não existe.
+
+## Quando reconsiderar
+
+Implantar OpenSIPS quando pelo menos uma destas condições existir:
+
+1. Mais de uma instância de Asterisk precisar compartilhar o mesmo conjunto
+   de troncos/roteamento.
+2. Necessidade de expor SIP a múltiplas operadoras com normalização de
+   roteamento antes do Asterisk.
+3. Volume que justifique uma camada de proteção SIP dedicada, separada do
+   Asterisk.
+
+## Esboço de integração futura
+
+- OpenSIPS ficaria na mesma rede privada do Asterisk (nunca IP público
+  direto no Asterisk — isso não muda).
+- Trunks/roteamento no domínio da aplicação (`Trunk` no Postgres) já
+  modelam host/porta/credenciais de forma genérica — o registro de
+  domínios `Trunk.host` como sendo o OpenSIPS em vez do Asterisk-tronco
+  direto é, na prática, uma mudança de configuração, não de schema.
+- Regras de firewall (`infrastructure/nftables/`) precisariam abrir a porta
+  SIP do OpenSIPS para a origem confiável (operadora/OpenSIPS peer),
+  mantendo o Asterisk inacessível de fora da rede interna.