Secure devcontainer fails when DNS resolver returns CNAME records alongside A records

What issue are you seeing?

The secure devcontainer fails during post_start.sh when the DNS resolver returns CNAME records alongside IPv4 A records.

Observed with the secure devcontainer configuration from:

```text id="9rzjlwm"
rust-v0.130.0

The startup aborts with:

```text id="ydjlwm"
ERROR: Invalid IPv4 address from DNS for auth.openai.com:
auth.openai.com.cdn.cloudflare.net.

The failure happens in the firewall initialization logic executed by post_start.sh.

The resolver output contains both the CNAME and the resolved IPv4 addresses, but the script currently expects every returned line to already be a valid IPv4 address.

What steps can reproduce the bug?

1. Clone the openai/codex repository.
2. Use the secure devcontainer configuration from rust-v0.130.0.
3. Open the workspace using the secure devcontainer configuration.
4. Start or rebuild the container.

The container startup fails during post_start.sh.

The issue can be reproduced on systems where:

```bash id="6jlwm0"
dig +short A auth.openai.com

returns output similar to:

```text id="d7jlwm"
auth.openai.com.cdn.cloudflare.net.
104.x.x.x
172.x.x.x

The firewall initialization logic aborts when processing the CNAME entry.

What is the expected behavior?

The secure devcontainer should start successfully even when the DNS resolver returns CNAME records alongside IPv4 A records.

Non-IPv4 DNS responses should be ignored or filtered before processing them in the firewall initialization logic.

Additional information

I verified the issue locally and confirmed that filtering the resolver output to valid IPv4 addresses resolves the problem.

Minimal fix here:
https://github.com/openai/codex/commit/2bbc364bcd89127be35b8fc8147b140ac3fe8e33

The issue appears to depend on resolver behavior and may therefore only affect certain environments or DNS configurations.