fix(podman): read a network's members on Podman 4.9 (#452)

[edgehero]

Closes #452. (Rebased onto the keeper, #463.)

What was wrong

On Podman 4.9.3, podman network inspect --format '{{json .Containers}}' exits 125 for every existing network (can't evaluate field Containers in type interface {}). Every podman caller of networkEndpoints therefore saw "unreadable":

• A network left by a kill -9ed doctor --live canary was reported "could not be read" on every run and never removed.
• The boot reaper, the sandbox network sweep and the live-probes peer sweep use the same read.

Measured (4.9.3 and 5.8.1)

command	4.9.3	5.8.1
network inspect --format {{json .Containers}}	exit 125, every network	exit 0, running and paused only
ps -a --filter network=N --format {{.Names}}\t{{.State}}	every member, every state	identical
ps -a on a missing network	exit 0, empty	same
network exists	0 present, 1 absent	same

The filter is an exact name match (a sibling N2 was not listed).

Change

• On podman, networkEndpoints reads members with ps -a and tells absent from unreadable with network exists. A line that is not a legal name, a tab and a lowercase state word means unreadable. Docker's .Containers read is unchanged.
• names keeps its meaning on both runtimes (running and paused members); podman adds parked for every other state.
• Each caller's rule is stated in INT-EGRESS-POLICY-CONTRACT: a dead run's probes are removed in any state, and other stopped members are detached.
• The stale-canary sweep is exported. The conformance script builds two leftovers the way runEgressCanary does and runs the real sweep with no bystander, asserting both are gone and the proxy still reaches out. Without the keeper, or with the podman read disabled, the case goes red on 4.9.3.
• Reaching these sweeps on 4.9 means they can detach the egress proxy, the podman 4.9: a job network teardown cuts the egress proxy off, so every later egress job gets 503 #458 trigger. So every network detach in the worker now goes through one helper, detachEndpoints, which asks one gate (makeDetachGate, worker/src/netns-keeper.mjs) before it detaches anything that is running:
  • Docker Engine, rootful Podman and Podman 5.x pass without a keeper read.
  • Rootless Podman 4.x, reached directly, through podman-docker or through its Docker API, needs the netns keeper holding right now; otherwise the network is left (keeper-not-holding), and so is one on a runtime that cannot be read (runtime-unreadable).
  • The runtime is read once per pass, bounded at 15 s / 1 MiB. A job teardown uses the runtime the job was admitted on, recorded per job, and a sandbox the runtime read at open, so a slow docker info at teardown never leaves a job network behind on Docker. Every refused teardown is logged.
  • The callers are job and sandbox teardown, the boot reaper, the sandbox sweep, and doctor's canary, stale-canary sweep and live-probe peers, on both venues. Opening an egress-armed sandbox on Podman 4.x refuses while the keeper does not hold.
• local through podman-docker on 4.9 falls back to the same member read, and the sandbox sweep passes the CLI's stderr through so the fallback fires there too.
• The boot reaper's steps are bounded (30 s each, 15 s for the runtime read).
• service uninstall names the Valkey volume only when a Valkey unit was removed.

Specs

INT-EGRESS-POLICY-CONTRACT, INT-LIVE-PROBE-CONTRACT, INT-SANDBOX-CONTRACT, DES-PODMAN-NATIVE-ROOTLESS-BACKEND, DES-EGRESS-DENY-ON-A-DEDICATED-NETWORK; docs/podman.md step 8, docs/egress.md.