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

docs/networking-design.md

@@ -118,6 +118,14 @@ container-mount-path second argument:
   occurrence — joins that network. No membership limit.
 - `--list-networks` / `--delete-network <name>` round out the set, mirroring
   `--list-volumes` / `--delete-volume`.
+- `--delete-network-full <name>` (landed later, once stale host state
+  actually caused a real problem — see the "Resolved" section below):
+  mirrors `--delete-volume-full`, but unlike that one it doesn't gate config
+  removal on teardown succeeding — a network's live state is multiple
+  independent pieces (rules, bridge, namespace), each individually
+  best-effort, since a piece "failing" because it was already removed by
+  hand is the expected case this exists to handle, not a reason to leave
+  the network stuck in the config.
 
 ## Config file schema
 
@@ -402,28 +410,30 @@ Landed as four commits (a fifth, this doc update, closes it out) — see
    real rootless session's pid alongside a hand-written matching record
    (left untouched) and a fabricated stale one (correctly swept).
 
-### Known gap: gateway/outside reachability unconfirmed
+### Resolved: gateway/outside reachability was stale host state, not a bug
 
-**Confirmed by testing, not yet root-caused.** Peer-to-peer connectivity
-through the tap+relay fallback is solid (verified above). Reaching the
-network's own gateway IP — and, in turn, the real outside through NAT — is
-**not**: neither ICMP nor a TCP `wget` ever got a response, despite ARP
-resolving correctly (the container's own `ip neigh` shows a `REACHABLE`
-entry with the gateway's real MAC, ruling out an L2/relay-framing problem).
-The identical bridge/subnet/host reached via veth instead of this fallback
-works perfectly — ruling out every environment-level explanation (host
-firewall, `rp_filter`, this dev sandbox's own networking) that would
-otherwise affect both paths equally, since those apply regardless of which
-mechanism connects the container. `rp_filter=0` (tried at the host-tap,
-bridge, and global `all` scope) did not fix it. Diagnosing further needs
-host-level tools (`tcpdump`, direct `iptables`/`sysctl` inspection) this
-project's `doas`-scoped root access during development didn't permit
-(restricted to running `slocker-lite` itself, no other commands). This
-needs re-verification — ideally on the actual veth-less target device,
-where the environment differs and this dev sandbox's own unidentified cause
-may simply not apply — before extern/outside connectivity through this
-fallback is relied on. `intern` networks (peer-to-peer only, no gateway
-involved at all) are unaffected by this gap.
+**Originally reported as an unconfirmed gap, now resolved.** An earlier pass
+of testing found gateway/outside reachability through the tap+relay
+fallback consistently failing (ICMP and TCP both unanswered), while the
+identical bridge/subnet reached via veth worked — with `rp_filter=0`
+(host-tap, bridge, and global `all` scope) tried and not fixing it. The
+actual cause turned out to be accumulated leftover bridges and iptables
+rules from many earlier rounds of manual testing on this same dev machine
+(this feature's `--delete-network`, before `--delete-network-full` existed,
+never tore down live host state — see that flag's own section below).
+**After manually clearing every leftover bridge and iptables rule and
+retesting on a clean host, gateway and outside reachability both work
+correctly through the tap+relay fallback**: 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 on port 80
+completed cleanly (a `wget` HTTP request against the same host separately
+segfaulted — confirmed to be a busybox `wget` bug unrelated to networking,
+reproducing identically regardless of which join mechanism was used).
+Inter-container connectivity was reconfirmed working at the same time.
+`--delete-network-full` (see below) exists specifically so this kind of
+stale-state accumulation can't recur — always prefer it over
+`--delete-network` when a network won't be recreated with the same name, or
+when testing repeatedly against the same name during development.
 
 ## Explicitly out of scope for now