docs: registrar bugs encontrados na verificação real em navegador

Usuário testou em produção e confirmou que os dois bugs do commit
anterior (Content-Type em requisições sem corpo, DELETE de supressão sem
motivo) estão corrigidos. Atualiza TODO.md/RELATORIO_FINAL.md para
refletir a verificação visual como concluída, e documenta a lição em
TROUBLESHOOTING.md: teste via curl prova que o backend funciona, não que
o frontend consegue falar com ele.

TODO.md

@@ -321,20 +321,22 @@ banco. Todos os fixtures de teste foram removidos/desativados ao final.
       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.
+- [x] **Verificação visual em navegador** — não foi possível durante a
+      construção (ambiente headless, sem display/browser); feita depois
+      pelo usuário real em `http://10.10.32.142/`, e **encontrou dois bugs
+      reais que o teste via curl nunca teria pego**: (1) o cliente HTTP do
+      frontend mandava `Content-Type: application/json` em requisições sem
+      corpo, e o Fastify rejeitava com 400 "body is empty" — quebrava
+      **todo** botão de ação sem payload (disponibilizar agente, pausar,
+      publicar dialplan, iniciar/pausar campanha, redefinir senha de
+      ramal); (2) botão "Desbloquear" da lista de bloqueio sempre falhava
+      porque a API exige motivo no corpo do DELETE e o cliente não tinha
+      como enviá-lo. Ambos corrigidos na raiz (função `request()` central)
+      e confirmados pelo usuário: "testei, funcionou". Detalhes em
+      `docs/TROUBLESHOOTING.md`. **Lição registrada**: testes via curl
+      provam que o backend funciona, não que o frontend consegue falar com
+      ele — teste real em navegador continua sendo necessário antes de dar
+      uma tela por concluída.
 
 ## Fase 9 — Segurança e produção
 - [x] Criptografia de segredos de trunk (AES-256-GCM) — já implementado na