[Request]: First-class container-to-container DNS discovery on custom networks

### Feature or enhancement request details

Please add first-class container-to-container DNS discovery for containers attached to the same `container` network, including bare container names and network aliases.

This came up while testing Compose-compatible workflows with `container-compose`. Compose users expect service names such as `web`, `db`, and network aliases to resolve from peer containers on the same network without a global host DNS setup step.

Related tracking:

- Existing DNS bug/discussion: https://github.com/apple/container/issues/856
- Compose compatibility tracker: https://github.com/Mcrich23/Container-Compose/issues/118
- Container-Compose service discovery issue: https://github.com/Mcrich23/Container-Compose/issues/114
- Container-Compose network aliases issue: https://github.com/Mcrich23/Container-Compose/issues/116

Current behavior on `container` 1.0.0:

```sh
container system start
container network create appnet
container run -d --name network-web --network appnet nginx:alpine
container run --rm --network appnet busybox:latest nslookup network-web
```

The peer container receives the network gateway as its resolver:

```sh
container exec network-web cat /etc/resolv.conf
# nameserver 192.168.65.1
```

The container is reachable by IP from the same network, but name lookup returns NXDOMAIN:

```text
Server: 192.168.65.1
Address: 192.168.65.1:53

** server can't find network-web: NXDOMAIN
```

The currently documented workaround appears to be configuring a DNS domain with `container system dns create ` plus setting `dns.domain`. That can make FQDN/search-domain flows work, but it is not the same as network-scoped, Compose-style service discovery. It also requires global host DNS configuration for what is usually expected to be a per-network container runtime feature.

A useful end state would be one of these:

1. Containers on the same network can resolve each other by container name, for example `web` -> that container's network IP.
2. The network layer supports additional network-scoped aliases so higher-level tools can map Compose service names and aliases onto Apple Container networks.
3. If bare names are intentionally out of scope, expose a supported CLI/API path that tools can use to create network-scoped DNS domains/aliases without requiring users to manually toggle global DNS settings.

Environment used for the repro:

```markdown
- OS: macOS 26.5.1 (25F80)
- Xcode: 26.5 (17F42)
- Container: container CLI version 1.0.0 (build: release, commit: ee848e3)
- Architecture: arm64
```

I agree to follow this project's Code of Conduct.

Start by reproducing the container network create, container run, container exec, and nslookup commands from the report, then trace the existing container network and system DNS flows, including container system dns create and dns.domain. Done means containers on the same custom network resolve container names or supported network aliases without requiring global host DNS configuration.

Written by the indexing model from the issue text.