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

[politerealism]

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)

[politerealism]

This is already being fixed — PR #3606 (fix(podman): restore host gateway alias mediation, opened before this issue) includes this exact fix as part of a broader change: "Mount a driver-owned, read-only /etc/resolv.conf that directs workload DNS to the supervisor at 127.0.0.53", using a Podman secret rather than uploading a file into the workload filesystem — the same approach considered here.

It goes further than a standalone fix would need to: it also resolves a trusted host gateway address with platform-specific defaults, rejects unsafe gateway addresses, persists the resolver config across sandbox restarts, cleans up the per-sandbox resolver secret on creation failure and deletion, and adds an E2E test plus architecture doc updates.

No separate fix needed here — closing this out in favor of #3606.

[politerealism]

Closing as redundant — superseded by #3606, which already implements this fix.