Resolve gateway/outside reachability gap: stale test state, not a bug

Retested the tap+relay fallback on a clean host after the user cleared
out accumulated leftover bridges and iptables rules from many earlier
rounds of manual testing (left behind because --delete-network never
tore down live host state before --delete-network-full existed).

With a clean host: a fresh --no-veth extern network's gateway IP and a
real external host both answered ICMP with 0% packet loss, and a raw
TCP connect (nc) to an external host completed cleanly. A separate
wget segfault against the same host was confirmed to be an unrelated
busybox bug (reproduces identically regardless of join mechanism), not
a networking issue. Inter-container connectivity was reconfirmed
working at the same time.

This closes out the previously-reported "gateway/outside reachability
unconfirmed" gap in docs/networking-design.md and CLAUDE.md -- both
peer-to-peer and gateway/outside connectivity through the tap+relay
fallback are now confirmed working on this dev machine.

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

CLAUDE.md

@@ -1033,29 +1033,28 @@ Source layout (all under `src/`):
   path**: two real containers joined the same network, each getting a
   distinct address (`10.168.0.2`/`10.168.0.3`) via the tap+relay path with
   no veth involved at all, and pinged each other successfully (0% packet
-  loss, confirmed repeatably). **Known gap, confirmed by testing, root
-  cause not yet identified**: neither container could reach the network's
-  own gateway IP (the address `provision_bridge()` assigns directly to the
-  bridge itself) — not with ICMP, not with a TCP `wget` — despite ARP
-  resolving correctly (confirmed via the container's own `ip neigh`/
-  `/proc/net/arp` showing a `REACHABLE` entry for the gateway's real MAC),
-  meaning L2 delivery through the relay is not at fault. The *exact same*
-  bridge, same subnet, same host, same MASQUERADE/`ip_forward` setup, but
-  joined via veth instead of this fallback, reaches the same gateway IP
-  perfectly (0% loss) — ruling out every environment-level explanation
-  (host firewall, `rp_filter`, this dev sandbox's own networking) that would
-  otherwise affect both paths identically. `net.ipv4.conf.<host-tap>
-  .rp_filter=0` (and broader `all`/bridge-scoped variants) was tried and
-  confirmed *not* to fix it. Root cause undetermined — diagnosing further
-  needs host-level tools (`tcpdump`, direct `iptables`/`sysctl` inspection)
-  this session's `doas` access doesn't permit (restricted to running
-  `slocker-lite` itself only). **This means gateway/outside reachability
-  through the tap+relay fallback is unconfirmed** — peer-to-peer
-  connectivity (an `intern` network's whole purpose, and half of what an
-  `extern` network offers) is solid; reaching the real internet through one
-  specifically needs re-verification, ideally on the actual veth-less
-  target device (a different kernel/environment where this dev sandbox's
-  own unidentified cause may not even apply) before being relied on.
+  loss, confirmed repeatably). **Gateway/outside reachability — originally
+  reported as an unconfirmed gap here, since resolved**: neither container
+  could initially reach the network's own gateway IP, despite ARP resolving
+  correctly (ruling out an L2/relay-framing problem) and the identical
+  bridge/subnet working perfectly via veth instead (ruling out every
+  environment-level explanation — host firewall, `rp_filter`, tried at
+  several scopes and confirmed not to fix it — since those would affect
+  both paths identically). **Actual cause, found once retested on a clean
+  host**: accumulated leftover bridges/iptables rules from many earlier
+  rounds of manual testing — `--delete-network` (before
+  `--delete-network-full` existed, see that flag's own entry below) never
+  tore down live host state, so stale rules/bridges from unrelated earlier
+  test networks were still present and interfering. After manually clearing
+  all of it and retesting fresh: a `--no-veth extern` network's gateway and
+  a real external host both answered ICMP with 0% loss, and a raw TCP
+  connect (`nc`) to an external host completed cleanly (a separate `wget`
+  segfault against the same host was confirmed to be an unrelated busybox
+  bug, reproducing identically regardless of join mechanism). Peer-to-peer
+  connectivity and gateway/outside reachability are both now confirmed
+  working through the tap+relay fallback on this dev machine —
+  `--delete-network-full` exists specifically so this class of
+  stale-state-masking-as-a-bug can't recur.
 
   **Crash-orphan sweep**, the direct tap+relay analog of `port_forward.h`'s
   own (see its own entry below): unlike a veth pair or a session's own