The flush-then-load pattern is the right instinct, and the EPERM discovery is the kind of thing that only shows up once you make the probe honest enough to hurt. Taking your closing question seriously, here are three places I would look for a pass that is not true.
The negative control proves the harness worked in phase one, then phase two assumes it still does. You verify the sniffer can see a packet with the ruleset flushed, and then you assert zero packets with the ruleset loaded, in a separate run. Anything that kills or stalls capture between those two runs gives you a clean green for exactly the reason you set out to eliminate. The stronger shape is a canary inside the same capture session as the assertion. You already have the ingredient: the bypassed UID that is supposed to reach the LAN. If that traffic must appear in the same pcap where the protected traffic must not, then an empty capture can never be read as a pass, because a working sniffer always has something in it.
Timing is doing unexamined work. Asserting zero captured packets immediately after the stimulus can pass because the packet has not been captured yet, which is a different claim from it never having left. If there is a sleep anywhere in there, it is load bearing and it will behave differently on a busy CI runner than on your laptop. An explicit drain, or sequencing against a marker packet you control, turns that from a race into an assertion.
The ephemeral namespace is cleaner than any machine this will actually run on. A fresh netns with only your ruleset in it tests your rules in isolation. Real hosts have Docker chains, a VPN client, systemd-resolved, and somebody's leftover UFW rules, all hooked at priorities you did not choose. Most leaks in this class of tool are interaction bugs between rulesets rather than errors within one, and a suite that always starts from an empty table structurally cannot see them. Even one test that loads a plausible conflicting ruleset first would cover a lot.
The fourth thing, and the one I would personally worry about most, is lifecycle. Your ten tests all look like steady state, loaded versus flushed. The windows that actually leak in transparent proxies tend to be at the edges: the gap between boot and rules loading, teardown ordering on stop, what happens when Tor itself crashes and the rules outlive it or do not, and interface flap or resume from suspend re-adding routes underneath you. Fails closed on crash is a real property and nothing in the list asserts it.
Good post. The willingness to publish "my tests were lying to me" is rarer than it should be, and it is most of why the rest of this is credible.
