Docs: the real DSM fix is bridge-nf-call-iptables=0, not an iptables rule

Confirmed on the operator's NAS. The earlier advice (insert an ACCEPT rule
ahead of DSM's chain) does not hold: DSM reloads its firewall periodically,
flushing and rebuilding the chains. You can watch FORWARD_FIREWALL's DROP
counter reset to zero and the inserted rule vanish with it, having matched no
packets. That is also why the symptom looked intermittent — 60/40 success on
repeated connections, with RELATED,ESTABLISHED keeping existing flows alive.

The fix is one level down: net.bridge.bridge-nf-call-iptables=0 takes
same-bridge traffic out of iptables entirely, so DSM's reloading cannot affect
it. Persisted with a Boot-up Triggered Task.

Section 8 now also answers "is that safe", accurately: the flag affects only
packets bridged within one network. Traffic between different Docker networks
is routed, so DOCKER-ISOLATION still applies; inbound traffic to published
ports is still routed and still firewalled; INPUT, which protects the NAS
itself, is untouched. The one real caveat is that it is host-wide, so VMs
sharing a bridge lose same-bridge filtering too.

The migrate failure message points at the sysctl now.

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

docker/entrypoint.sh

@@ -72,10 +72,10 @@ print(
 print(
     "[entrypoint] If this is a Synology NAS: DSM's firewall filters traffic "
     "between containers (FORWARD -j FORWARD_FIREWALL runs before Docker's own "
-    "rules and denies by default). Fix:\n"
-    "    iptables -I FORWARD 1 -i docker+ -o docker+ -j ACCEPT\n"
-    "See docs/nas-install.md, 'DSM firewall blocks container-to-container "
-    "traffic'.",
+    "rules and ends in DROP), and it reloads periodically, so an added iptables "
+    "rule does not survive. Fix:\n"
+    "    sysctl -w net.bridge.bridge-nf-call-iptables=0\n"
+    "See docs/nas-install.md section 8.",
     file=sys.stderr,
 )
 sys.exit(1)