fix: harden firewall and traffic reconciliation

docs/ANTI_TORRENT.md

@@ -89,15 +89,17 @@ max_connections_per_peer = 500
 
 `ct count` использует conntrack. Для примера 23 peers × 500 flows дают до 11 500 потенциальных flow slots перед ограничением каждого peer. Само по себе это не является доказательством достаточной ёмкости конкретного хоста, поэтому фактическое состояние conntrack обязательно наблюдается.
 
-Что надо мониторить:
+Что надо мониторить (count — в namespace, где работает guard; max — глобально на host):
 
 ```bash
-sysctl net.netfilter.nf_conntrack_count
+C="$(docker ps --format '{{.Names}}' | grep -E '^(amnezia-awg2|amnezia-awg)$' | head -n1)"
+AWG_PID="$(docker inspect -f '{{.State.Pid}}' "$C")"
+nsenter -t "$AWG_PID" -n -- sysctl net.netfilter.nf_conntrack_count
 sysctl net.netfilter.nf_conntrack_max
-nft list table inet awg2_harness
+nsenter -t "$AWG_PID" -n -- nft list table inet awg2_harness
 ```
 
-Если `nf_conntrack_count` приближается к `nf_conntrack_max`, проблема уже системная: надо разбираться с timeout, abuse или capacity. `awg2-harness status` показывает оба значения и вычисленный `nf_conntrack_utilization`, чтобы давление было видно без ручного деления. Не надо автоматически увеличивать `nf_conntrack_max` из orchestrator без отдельного решения.
+Если `nf_conntrack_count` приближается к `nf_conntrack_max`, проблема уже системная: надо разбираться с timeout, abuse или capacity. `awg2-harness status` показывает `count_namespace`, count, глобальный max и вычисленный utilization. При недоступном container namespace host count намеренно не подставляется. Не надо автоматически увеличивать `nf_conntrack_max` из orchestrator без отдельного решения.
 
 ## 7. Критерии приёмки