feat(frontend): Call Center > Filas/Pausas/Disposições, Telefonia > Troncos, Discador > Lista de Bloqueio

Cinco telas novas no app do tenant, todas contra endpoints de backend que já
existiam (Queues/PauseReasons/Dispositions/Trunks/Suppression) — mesmo padrão
de listagem+form inline+remoção com confirmação de 2 cliques usado em Ramais.
StatusBadge ganhou o mapa de TrunkStatus. Corrigido bug real: PauseReasonsController.list()
não filtrava enabled:true, então um motivo removido nunca sumia da lista.
Testado ponta a ponta contra a API real do tenant Acme.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BFaBaBSQGhyXGEgtTYZGV8

TODO.md

@@ -866,7 +866,46 @@ app do Tenant + Dashboard (agente.md secao 162, 169)
       (secao 161) — `stats`/`callsInFlight` só atualizam ao recarregar
       a página, não em tempo real
 
-## PHASE 27+ — ver `agente.md` seções 140 em diante (resto do Frontend,
+## PHASE 27 — Frontend: Call Center > Filas/Pausas/Disposições, Telefonia >
+Troncos, Discador > Lista de Bloqueio (agente.md secao 50-51, 41-42, 71,
+89, 169)
+- [x] 5 telas novas, mesmo padrão de listagem+form inline+remoção com
+      confirmação de 2 cliques já usado em Ramais/Tarifas: `/app/callcenter/
+      filas`, `/app/callcenter/pausas`, `/app/callcenter/disposicoes`,
+      `/app/telefonia/troncos`, `/app/discador/bloqueio` — todas contra
+      endpoints que já existiam desde as fases de backend (Queues/
+      PauseReasons/Dispositions/Trunks/Suppression), nenhum endpoint novo
+      precisou ser criado
+- [x] `lib/callcenter-types.ts` (novo): tipos `Queue`/`Trunk`/`PauseReason`/
+      `Disposition`/`SuppressionEntry` compartilhados entre as 5 telas
+- [x] `StatusBadge` ganhou o mapa de `TrunkStatus` (UP/REGISTERED/DOWN/
+      TRYING/FAILED/UNREGISTERED/UNKNOWN) — mesmo componente usado por
+      Campanhas, sem colisão de chave com `CampaignStatus`
+- [x] `nav-data.ts`: as 5 rotas saem de "em breve" pra link real; resta só
+      Agentes (Call Center), Dialplan (Telefonia), Leads/Importações/
+      Callbacks (Discador) "em breve" no menu Tenant
+- [x] **Bug real, achado testando a tela de Pausas**:
+      `PauseReasonsController.list()` era o único endpoint do arquivo sem
+      filtro `enabled: true` — um motivo removido (soft delete) nunca
+      sumia da listagem. Corrigido.
+- [x] Testado ponta a ponta contra a API real (tenant Acme) depois de
+      reerguer `apps/api` e `apps/frontend` do zero pós-reboot da VM (ver
+      "Riscos conhecidos" — os dois rodam direto no host, fora do
+      docker-compose, e não voltam sozinhos): criar fila/pausa/disposição/
+      tronco/bloqueio de número → aparece na lista com os dados certos →
+      remover com confirmação de 2 cliques → lista volta ao estado vazio.
+      Screenshots em `apps/frontend/.impeccable/review/`.
+- [ ] Editar campos existentes (só create/list/delete em todas as 5,
+      mesma limitação já documentada em Ramais) — nenhum backend novo tem
+      PATCH/PUT ainda
+- [ ] Tronco: `Trunk.status` continua sem atualização automática em
+      produção (lacuna já documentada na PHASE 09/TRUNKS.md) — a tela só
+      exibe o `StatusBadge`, não força refresh nem faz polling
+- [ ] Dark mode e mobile não foram capturados nesta fase (só desktop
+      light, mesma decisão de escopo das últimas telas simples) —
+      reavaliar junto com a Sidebar quando "Agentes" ganhar tela própria
+
+## PHASE 28+ — ver `agente.md` seções 140 em diante (resto do Frontend,
 Security, Tests)
 
 ---
@@ -878,3 +917,17 @@ Security, Tests)
   simultâneos — reavaliar quando chegarmos lá.
 - **Disco (26GB livre)**: build do FreeSWITCH + imagens Docker + gravações vão consumir
   espaço rápido. Monitorar com `df -h`.
+- **RAM da VM aumentada pra 8GB em 2026-08-29** — resolve a preocupação acima, mas
+  ainda não tem swap generoso nem monitoramento de pico durante um build de frontend +
+  todos os workers rodando junto; reavaliar se o Next.js dev server crescer muito.
+- **`apps/api` e `apps/frontend` rodam direto no host** (`pnpm dev`), fora do
+  docker-compose — só Postgres/Redis/FreeSWITCH/fs-config/fs-events/predictive-dialer/
+  ai-worker são containers. Depois de qualquer reboot da VM (como o desta sessão, pra
+  aplicar a RAM nova) os containers voltam sozinhos (restart policy do compose), mas
+  os dois processos de host **não voltam** — precisam ser religados manualmente:
+  `apps/api` precisa de `set -a && source .env && set +a` antes (não lê `.env`
+  sozinho, ao contrário dos containers) e deve subir **antes** do frontend, porque os
+  dois usam a porta 3000 por padrão (`API_PORT` não setado, `next dev` sem `-p`) — o
+  segundo a subir cai sozinho pra 3001. `B2BCALL_API_URL` do frontend
+  (`apps/frontend/.env.local`) assume que a API ficou com a 3000, então a ordem
+  importa. Sem um processo supervisor (pm2/systemd) isso vai se repetir a cada reboot.