Root cause: Pi, the ISP router (FritzBox), and LAN clients share the same
L2 segment. When Pi forwards a client's IPv6 packet to an external GUA
destination, the Linux kernel detects that the ISP router is a "better"
next-hop on the same link and sends an ICMPv6 Redirect (type 137) to the
client. The client obeys the redirect and sends its first SYN to the ISP
router directly — Pi never forwards the original packet. The ISP router
applies per-device content filtering to the unmasqueraded client GUA and
issues a RST. This produced the symptom of the first IPv6 request failing
with "Connection reset by peer" every ~30-60 seconds (matching the FritzBox
RA interval, after which clients re-resolve their default gateway).

Diagnosis method: tcpdump with MAC addresses (-e flag) on Pi's end0 caught
the ICMPv6 Redirect being sent immediately after the first SYN arrived.
Inserting a DROP rule for icmpv6-type redirect at position 1 in ip6tables
OUTPUT confirmed the fix — 0 failures across extended testing.

Fix:
- Drop ICMPv6 Redirect (type 137) in ip6tables OUTPUT as the first rule,
  before the ACCEPT rule, in both direct and VPN modes
- Flush ip6tables OUTPUT chain on clear_rules() instead of per-rule -D
  deletion, which was fragile and left stale rules accumulating across
  mode switches (previously caused duplicate/conflicting OUTPUT rules)
- Flush ip6tables nat POSTROUTING table instead of per-rule -D deletion
  for the same reason

Also documents the ICMPv6 Redirect issue and IPv6 masquerade rationale
in roles/gateway/README.md for future reference.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

This is to allow the ansible-distro-install to safely call the bootstrap
playbook without getting validation errors about the other configure
roles (especially if they are not configured yet, or if running on CI)

This also improves the dependency management, making the roles less
repeating when not needing to execute multiple times

This reverts commit fdd0b5b58f0ebd39ad05e2dcb17faa6603145f97.