docs: atualizados padroes de DNS do Wireguard e sincronizacao de chaves no Gitea

arquitetura.md

@@ -216,6 +216,12 @@ A rede VPN WireGuard (`10.99.0.0/24`) deixa de ser tratada como uma zona de conf
   - Permitir VPS 4 (Staging)   -> VPS 3 (Produção - Outras portas / serviços)   [BLOQUEAR]
   ```
 
+* **🌐 DNS e Acesso Seguro à Internet no WireGuard**:
+  Na topologia estrela (*Hub-and-Spoke*), as VPSs clientes utilizam o túnel estritamente para tráfego privado (`AllowedIPs = 10.99.0.0/24`). Para evitar que as máquinas fiquem offline ou sem resolução de nomes (DNS Timeouts), aplica-se a seguinte diretriz de design:
+  * **Omissão da Diretiva `DNS`**: Os arquivos `wg0.conf` dos clientes (**nunca**) devem declarar a diretiva `DNS = 1.1.1.1` ou similar.
+  * **Explicação**: Se declarada, o gerenciador `systemd-resolved` tenta forçar as consultas de DNS pela interface virtual `wg0`. Como os servidores DNS são IPs públicos fora da faixa `10.99.0.0/24`, as consultas de DNS são descartadas pela criptografia do túnel, deixando o sistema e quaisquer agentes de IA totalmente incapazes de resolver nomes de internet e APIs externas.
+  * **Padrão Correto**: Remover a linha `DNS` das interfaces dos clientes para que as consultas de internet continuem sendo resolvidas instantaneamente via interface pública de uplink (`eth0`), mantendo a conectividade do host estável.
+
 ---
 
 ### 4. 🎛️ Migração de Borda: nftables + CrowdSec
@@ -245,3 +251,16 @@ Para garantir que a invasão de um container não resulte no comprometimento do
 * **Read-Only Root Filesystem**: Monta o sistema de arquivos do container como apenas leitura, forçando gravações temporárias apenas em volumes declarados ou `/tmp` na memória (tmpfs).
 * **CAP Drop**: Remove capacidades de sistema desnecessárias ao container (ex: `NET_ADMIN`, `SYS_ADMIN`, `SYS_CHROOT`).
 * **Rootless Containers**: Sempre que suportado pela aplicação, os containers devem rodar com IDs de usuário não privilegiados (non-root).
+
+---
+
+### 7. 🔗 Sincronização e Orquestração de Estado no Gitea
+Como os agentes de IA operam sob restrições rígidas de movimentação lateral Zero-Trust (sem permissões de SSH automático irrestrito entre as VPSs), o Gitea atua como o orquestrador assíncrono de estado e documentação da infraestrutura.
+
+* **Sincronização Física do Arquivo `authorized_keys`**:
+  Ao gerenciar ou inserir chaves públicas (`Deploy Keys` ou `Public Keys` de usuários) diretamente no banco de dados do Gitea (`PostgreSQL:giteadb`) ou por rotinas externas, a tabela do banco de dados sincroniza, mas o arquivo de chaves autorizado físico do daemon de SSH do Gitea (porta 2222) não é reescrito de forma imediata. Isso gera erros de rejeição de chave SSH nos clientes durante tentativas de `git clone` ou `git pull`.
+* **Solução via Gitea CLI**:
+  Para reescrever de forma limpa e forçada o arquivo físico de chaves SSH autorizadas e restabelecer imediatamente a sincronização de agentes e repositórios sem necessidade de intervenção humana ou cliques manuais na interface web, executa-se o utilitário nativo de administração de dentro do host do Gitea (VPS 3):
+  ```bash
+  sudo -u git GITEA_WORK_DIR=/var/lib/gitea /usr/local/bin/gitea --config /etc/gitea/app.ini admin regenerate keys
+  ```