docs: registrar liberação de SIP/RTP no firewall e confusão de senhas

Atualiza TODO.md/SECURITY.md para refletir a regra de nftables real (SIP/
RTP liberados para RFC1918, AMI/ARI seguem bloqueados incondicionalmente)
e documenta em TROUBLESHOOTING.md o caso completo: timeout de registro de
softphone causado pelo firewall + confusão entre senha de login web e
senha SIP do ramal (duas credenciais diferentes).

docs/TROUBLESHOOTING.md

@@ -3,6 +3,38 @@
 Problemas reais encontrados durante o desenvolvimento deste projeto e como
 foram diagnosticados/resolvidos — mantido como referência para o futuro.
 
+## Softphone não registra ("timeout")
+
+**Sintoma**: usuário criou um ramal, colocou usuário/senha num softphone
+real e o registro dava timeout (sem resposta nenhuma do servidor).
+
+**Causa raiz nº 1 — firewall**: nftables bloqueava incondicionalmente SIP
+(5060/udp) e RTP (10000-20000) vindos da interface LAN (`ens18`) — regra
+criada na Fase 2 como proteção, mas que também bloqueia qualquer uso real,
+já que o OpenSIPS que ficaria na frente (`docs/OPENSIPS.md`) nunca foi
+implantado. Diagnosticado direto pelo contador da regra:
+`nft list table inet b2bcall_fw` mostrando `udp dport 5060 ... drop` com
+contador subindo a cada tentativa. **Fix**: liberar SIP/RTP para origem
+RFC1918 (rede privada), mantendo AMI/ARI sempre bloqueados — ver
+`docs/SECURITY.md`.
+
+**Causa raiz nº 2 — depois de liberar o firewall, "Failed to authenticate"**:
+o usuário estava digitando a **senha de login web** (a do `admin@b2bcall.
+local`) no campo de senha do softphone, em vez da **senha SIP** do próprio
+ramal (que é uma credencial completamente diferente, gerada por ramal).
+Confirmado ativando `pjsip set logger on` e vendo o REGISTER chegando e
+falhando na autenticação. **Lição**: deixar claro na interface (ou pelo
+menos na documentação) que são dois sistemas de credenciais distintos —
+fácil de confundir porque os dois são "a senha que o sistema gerou".
+
+**Melhoria feita por causa disso**: antes, a única forma de recuperar uma
+senha SIP esquecida era resetá-la (invalidando a anterior). Agora dá para
+ver e editar a senha SIP diretamente no formulário de edição do ramal
+(`GET /extensions/:id/password`, decifra sob demanda) — diferente da
+senha de login (hash argon2id, irreversível por design), a senha SIP é
+cifrada (reversível) porque o próprio Asterisk precisa dela em texto puro
+para autenticar.
+
 ## "Body cannot be empty when content-type is set to 'application/json'" em quase todo botão de ação
 
 **Sintoma**: usuário real testando no navegador (não `curl`) relatou erro