[Request]: Option for DNS forwarding to host resolver through vsock.

### Feature or enhancement request details

macOS facilitates DNS resolution for applications running in VMs by running a server on port 53 when any VM is running. You can see this behavior by starting any container and then running:

```console
% sudo lsof -i :53
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
mDNSRespo 425 _mdnsresponder 43u IPv4 0xc17b848abc118146 0t0 UDP *:domain
mDNSRespo 425 _mdnsresponder 47u IPv6 0xe19516711ac186cf 0t0 UDP *:domain
mDNSRespo 425 _mdnsresponder 50u IPv4 0xabee510e0e346f0e 0t0 TCP *:domain (LISTEN)
mDNSRespo 425 _mdnsresponder 61u IPv6 0xd8e4cba3d9c294df 0t0 TCP *:domain (LISTEN)
```

VMs can reach this server by directing requests to port 53 on the NAT bridge gateway address. The default resolver configuration for a container uses this approach (here with `test` configured as the default local domain for containers):

```console
% container run alpine:latest cat /etc/resolv.conf
nameserver 192.168.64.1
domain test
```

If any other application (e.g. Tailscale, zScaler, dnsmasq) tries to run a server on port 53, the user winds up in a situation where either that application fails to operate properly (because macOS is already running its server), or container name resolution fails (because the third-party application is already listening on 53).

Short of a change to macOS' DNS handling we don't have a good way to address the former case, other than for the user to ensure the third-party server is always first to start.

For the latter case, users can use `container run --dns ip-addr` to configure the container's resolver, but this will result in requests bypassing container's scoped request resolver, so container name resolution (e.g. `webserver.test`) won't work.

One possibility for addressing this would be to include an option to starts a lightweight DNS forwarder inside the VM that communicates with the sandbox helper. The sandbox helper could convert hostname queries to library calls that the macOS DNS service can fulfill without relying on the port 53 DNS server.

### Code of Conduct

- [x] I agree to follow this project's Code of Conduct

Start by tracing the sandbox helper and the container DNS configuration described in the issue, including the `container run --dns` entry point. Define an option for a VM-side DNS forwarder that reaches macOS DNS through the sandbox helper, while preserving scoped container name resolution and avoiding reliance on port 53.

Written by the indexing model from the issue text.