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/INSTALL.md

@@ -0,0 +1,92 @@
+# B2BCall — Instalação
+
+## Requisitos
+
+- Debian 13 (trixie) limpo, acesso root.
+- **Mínimo para dev/testes/simulação**: 2 vCPU, 2 GiB RAM, 20 GiB disco.
+- **Recomendado para produção real com volume de discagem**: 4 vCPU, 8 GiB
+  RAM (ver `docs/ARCHITECTURE.md` §1 — o ambiente original de
+  desenvolvimento deste projeto tinha só 1.9 GiB e isso limitou decisões de
+  arquitetura, como resource limits conservadores por container).
+- Rede: um IP privado para o servidor; troncos SIP/OpenSIPS acessíveis por
+  IP privado (o Asterisk nunca tem IP público — seção 5).
+
+## Instalação automatizada
+
+```bash
+git clone <url-do-repositorio> /opt/b2bcall
+cd /opt/b2bcall
+sudo ./scripts/install.sh
+```
+
+O script (`scripts/install.sh`) faz, em ordem:
+
+1. Verifica que está rodando como root.
+2. Instala dependências de sistema (git, curl, openssl, Node.js 24 LTS via
+   NodeSource, pnpm via corepack).
+3. Instala Docker Engine + Compose plugin (repositório oficial Docker,
+   detecta o codename da distro automaticamente).
+4. Gera `.env` a partir de `.env.example` com segredos aleatórios fortes
+   (`scripts/generate-secrets.sh`) — só na primeira instalação, nunca
+   sobrescreve um `.env` existente.
+5. Instala as regras de firewall (`infrastructure/nftables/`) — protege
+   AMI/ARI/SIP contra a LAN, nunca bloqueia SSH.
+6. Aplica `vm.overcommit_memory=1` (recomendado pelo Redis).
+7. `pnpm install` no monorepo.
+8. `docker compose build` (compila Asterisk do fonte — a etapa mais
+   demorada, ~5-10 minutos dependendo do hardware).
+9. Sobe Postgres e Redis, aguarda ficarem saudáveis.
+10. Aplica migrations do Prisma e roda o seed (permissões, perfis,
+    bootstrap do `super_admin`).
+11. Sobe Asterisk e os demais serviços (`docker compose up -d`).
+12. Roda `scripts/healthcheck.sh`.
+13. Imprime a URL de acesso e o caminho do `FIRST_LOGIN.txt`.
+
+## Primeiro acesso
+
+```bash
+cat FIRST_LOGIN.txt
+```
+
+Contém e-mail e senha do `super_admin`, gerados aleatoriamente
+(agente.md seção 70) — nunca uma senha padrão. O primeiro login **exige**
+troca de senha (`mustChangePassword: true`).
+
+**Remova o arquivo do servidor depois do primeiro acesso**:
+
+```bash
+shred -u FIRST_LOGIN.txt   # ou: rm -f FIRST_LOGIN.txt
+```
+
+## Acesso
+
+- Interface web: `http://<ip-do-servidor>/`
+- API: `http://<ip-do-servidor>/api` (Swagger em `/api/docs` se
+  `SWAGGER_ENABLED=true`)
+
+Nenhuma outra porta deve estar acessível pela LAN além de 80 (e 443 quando
+HTTPS for configurado — ver `docs/OPERATIONS.md`).
+
+## Instalação manual (passo a passo, se preferir não usar o script)
+
+Ver o conteúdo de `scripts/install.sh` — cada etapa pode ser executada
+isoladamente. Pontos que merecem atenção especial se for fazer manualmente:
+
+- **Ordem de subida**: Postgres/Redis saudáveis → migrations → Asterisk →
+  demais serviços. Subir tudo de uma vez com `docker compose up -d` também
+  funciona (o `depends_on: condition: service_healthy` do
+  `docker-compose.yml` já orquestra isso), mas as migrations/seed do Prisma
+  precisam rodar manualmente contra o Postgres antes da API funcionar de
+  verdade (a API não roda migrations automaticamente no boot — decisão
+  deliberada para nunca alterar schema de produção sem um passo explícito).
+- **DATABASE_URL para comandos rodados do host** (fora dos containers):
+  use `127.0.0.1` como host, não `postgres` — ver
+  `docs/ARCHITECTURE.md` §3.2.1.
+
+## Atualizando uma instalação existente
+
+```bash
+sudo ./scripts/update.sh
+```
+
+Ver `docs/OPERATIONS.md` para detalhes.