feat: add frontend, nginx reverse proxy and monitoring/reports extras

- apps/frontend: Next.js 15 (App Router) + Tailwind v4 + componentes estilo
  shadcn/ui sobre Radix UI + TanStack Query. Tema light/dark, logo
  processada. Menu completo (secao 52) com gating por permissao real.
  Todas as telas do checklist de aceite (secao 90) conectadas a endpoints
  reais (nao mockup): login, usuarios, perfis/permissoes, ramais/troncos,
  dialplan, filas/agentes, console do agente, campanhas (CPS/CSV/
  iniciar/pausar), monitoramento ao vivo (polling, nao WebSocket real),
  TME/TMA, busca/export de chamadas, administracao do Asterisk, auditoria
- infrastructure/nginx: reverse proxy colocando frontend+API na mesma
  origem (porta 80), antecipado da Fase 9 pois a API nao publica porta
  propria
- apps/api: GET /api/monitoring/agents (estado corrente real via
  agent_state_events em aberto) e filtro queueId em GET /api/reports/calls

Pendencia registrada: tela de Callbacks nao implementada (schema existe
desde a Fase 6, mas nunca houve controller/service — construir a tela sem
API real seria mockup). Verificacao visual em navegador nao foi possivel
neste ambiente headless; validado via tsc/eslint/next build limpos + curl
reproduzindo as chamadas do navegador (middleware de auth, 24 paginas
protegidas via Nginx, endpoints de dados com cookie de sessao).

TODO.md

@@ -273,10 +273,52 @@ relatórios/dashboard/compliance retornando dados reais e coerentes com o
 banco. Todos os fixtures de teste foram removidos/desativados ao final.
 
 ## Fase 8 — Frontend completo
-- [ ] Bootstrap Next.js + Tailwind + shadcn/ui + TanStack Query + WS client
-- [ ] Logo processada (b2bcall.png) + tema light/dark
-- [ ] Menu completo (seção 52)
-- [ ] Todas as telas do checklist de aceite (seção 90)
+- [x] Bootstrap Next.js 15 (App Router) + Tailwind v4 + componentes estilo
+      shadcn/ui (escritos à mão sobre Radix UI, sem CLI interativo) +
+      TanStack Query. WS client não implementado (ver nota abaixo) —
+      telas ao vivo usam polling via `refetchInterval` (5–15s conforme a
+      tela), suficiente para o volume atual mas não é WebSocket real.
+- [x] Logo processada (`b2bcall.png` copiada, original nunca modificada) +
+      tema light/dark com toggle manual + `prefers-color-scheme`.
+- [x] Menu completo (seção 52) com gating por permissão real
+      (`RequirePermission` + itens de menu ocultos por `useAuth().can()`),
+      Dashboard/Discador/Call Center/Telefonia/Monitoramento/
+      Relatórios/Sistema + Console do Agente.
+- [x] Reverse proxy Nginx (`infrastructure/nginx/`) colocando frontend e
+      API na mesma origem (porta 80, único serviço publicado à LAN) —
+      antecipado da Fase 9 (seção 87) porque sem isso não havia como um
+      navegador de verdade alcançar a API (que não publica porta própria).
+- [x] Todas as telas do checklist de aceite (seção 90) implementadas e
+      conectadas a endpoints reais: login, usuários, perfis/permissões,
+      ramais, status de ramal, troncos, dialplan, filas, agentes,
+      associação agente↔fila, motivos de pausa, console do agente
+      (login/pausa/retirar pausa), campanhas (CPS, importação CSV,
+      iniciar/pausar), monitoramento (discagem/agentes/fila) ao vivo,
+      TME/TMA, busca de chamadas com filtro por fila/agente/estado/
+      telefone/data, exportação CSV, administração do Asterisk
+      (status + diagnóstico allowlist + reload), auditoria.
+      Adicionado `queueId` a `GET /api/reports/calls` (não existia antes)
+      para permitir o filtro por fila explicitamente pedido na seção 90.
+- [ ] Callbacks (menu da seção 52) — **não implementado nesta fase**: o
+      modelo `Callback` existe no schema desde a Fase 6, mas nunca houve
+      controller/service de API para ele, e a seção 90 (critério literal de
+      aceite) não exige essa tela. Criar uma tela sem a API por trás seria
+      construir um mockup, o que a diretriz do projeto proíbe. Fica
+      registrado como pendência explícita, não descartado silenciosamente.
+- [ ] **Verificação visual em navegador não foi possível nesta sessão** —
+      ambiente é um servidor Debian headless sem display/browser. A
+      verificação feita foi: `tsc --noEmit` limpo, `eslint` limpo, build de
+      produção (`next build`) gerando as 27 rotas sem erro, e testes
+      funcionais via `curl` reproduzindo exatamente as chamadas que o
+      navegador faria — login via `/api/auth/login`, cookie de sessão
+      validado pelo middleware (`/` redireciona para `/login` sem cookie,
+      libera com cookie), todas as 24 páginas protegidas retornando HTTP
+      200 através do Nginx, e os endpoints de dados (`/api/dashboard`,
+      `/api/reports/*`, `/api/compliance/*` etc.) retornando dados reais
+      com o mesmo cookie de sessão. O que **não** foi verificado: renderização
+      visual real, interações de clique/formulário no DOM, responsividade,
+      tema escuro na prática. Recomenda-se ao usuário abrir
+      `http://10.10.32.142/` em um navegador para essa validação final.
 
 ## Fase 9 — Segurança e produção
 - [ ] Criptografia de segredos de trunk (AES-256-GCM)