bug(podman): workload gets no /etc/resolv.conf under network:none, unlike Docker's nameserver 127.0.0.53 #3645

User Story

As an operator running sandboxes via the Podman driver, I want DNS resolution to work the same way it does with Docker, so sandboxed processes can resolve policy-permitted hostnames without a manual workaround.

Problem Statement

Podman workload containers run with NetworkMode: none (per RFC 0012's isolation model), and Podman does not manage DNS for network-less containers at all — /etc/resolv.conf is left exactly as whatever the base image happens to ship. The Docker driver, by contrast, explicitly configures nameserver 127.0.0.53 in the workload's /etc/resolv.conf, which the sandbox's DNS mediation (network_broker.rs's classify_send) specifically relays only when the destination matches that exact relay address. Podman workloads get no equivalent configuration.

Impact / Why This Matters

Confirmed independently twice:

• During investigation of bug(supervisor-network): boundary reconnect is followed by proxy exit and ControlSupervisorExited #3396, DNS resolution silently failed for a Podman-driven sandbox using ghcr.io/astral-sh/uv:python3.12-bookworm-slim (no systemd-resolved convention baked in) — required building a custom local image with /etc/resolv.conf hand-baked via COPY to get DNS interception working at all.
• PR fix(sandbox): keep boundary connection live under stalled relays #3642 hit the identical gap independently: "The Podman workload runs with NetworkMode: none and gets no /etc/resolv.conf, while the Docker driver sets nameserver 127.0.0.53. I wrote that line into the workload's /etc/resolv.conf by hand."

Any real-world Podman deployment using a base image that doesn't already happen to ship the 127.0.0.53 convention will silently fail DNS resolution for every sandboxed process — including for hostnames the policy explicitly allows — with a generic DNS lookup error rather than any actionable diagnostic pointing at the real cause.

Acceptance Criteria

• The Podman driver explicitly writes or mounts /etc/resolv.conf (pointing at the sandbox's internal DNS relay address) into the workload container at creation time, matching Docker's behavior, regardless of what the base image ships
• This does not depend on Podman's own network-mode-specific DNS management, since network: none skips that entirely
• Behavior is consistent across rootful and rootless Podman
• A regression test covers DNS resolution working correctly from a Podman-driven sandbox using a base image with no pre-existing DNS relay convention

Reproduction Steps

1. Create a Podman-driven sandbox from an image with no nameserver 127.0.0.53 baked into /etc/resolv.conf (e.g. ghcr.io/astral-sh/uv:python3.12-bookworm-slim).
2. Apply a policy allowing a specific hostname (openshell policy update --wait --binary <bin> --add-endpoint <host>:443:read-only <sandbox>).
3. Attempt to resolve that hostname inside the sandbox (getent hosts <host>).
4. Resolution fails with a DNS error, even though the host is explicitly policy-permitted.

Environment

• OpenShell current main (post RFC 0012, post PR fix(sandbox): keep boundary connection live under stalled relays #3642)
• Compute driver: Podman (rootful and rootless)
• OS: Linux

Related: #3396, PR #3642 (follow-ups section)