fix(sandbox): keep a session's transparent egress up on its own

[yannickmonney]

On the default session path (runc + transparent egress), two single points of failure left a session silently without egress for its whole life: one failed name lookup of the egress proxy at boot, and a redsocks process that exited.

Changes

fix(sandbox): keep a session's transparent egress up on its own

A session resolved the egress proxy's name once at boot. When the egress
container was restarting or not yet registered with Docker's resolver,
that one miss left the session without transparent egress for its whole
life: proxy-ignorant clients (Node's fetch, raw sockets, nested
containers) failed until the container was recreated. The boot now asks
again for up to about five seconds (1, 2 and 2 s apart) before giving up;
the first answer is still used at once.

The OUTPUT redirect sends every public connection to redsocks, which was
started once in the background: a redsocks that died left the session
with no transparent egress and nothing noticed. It now runs under a
restart loop, as the redsocks uid itself so no root process stays behind,
with a delay doubling from 1 s to 30 s and back to 1 s after a minute's
good run.

Verification

• runtime daemon: new session-egress-recovery.test.ts (4 tests: first answer used at once, retries until the name resolves, bounded give-up, redsocks restarted after it exits) fails 3/4 against the previous entrypoint; inner-docker-network.test.ts, build-cache-startup.test.ts, entrypoint-dispatch.test.ts pass (the fake redsocks there now ends its restart loop so the tests' wait returns).
• @tale/sandbox-runtime-daemon typecheck and lint clean; lint:manual ok.
• Not observed live: an egress restart under a running session (deployment check).

Part of the sandbox footprint and robustness pass (#4533, #4538 and siblings).