[Bug]: no routing to network available from host

### I have done the following

- [x] I have searched the existing issues
- [ ] If possible, I've reproduced the issue using the 'main' branch of this project

### Steps to reproduce

Disclaimer: I'm not sure it's an apple/container bug/feature request, but as far as I could debug, it looks like it.

I have Cloudflare Zero Trust WARP client (https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/warp/download-warp/) running on my Mac. Implementation-wise it's a PtP utun network device with a CGNAT 100.96.0.0/12 IP (in other words, I don't think it's specific to CF ZT WARP, but will be problematic for anything implemented similarly):
```
~ ifconfig utun4
utun4: flags=8051 mtu 1280
inet 100.96.0.X --> 100.96.0.X netmask 0xffffffff
inet6 A%utun4 prefixlen 64 scopeid 0x20
inet6 Z prefixlen 128
nd6 options=201
```

It provides access to another network (let's say my local network is 192.168.0.0/24 on en0 and CF ZT WARP provides access to 192.168.1.0/24). Implementation-wise there is a 192.168.1.0/24 route via utunX:
```
~ netstat -rn -finet | grep -F -e 100.96/12 -e 192.168.1
100.96/12 utun4 Uc utun4
192.168.1 utun4 Uc utun4
```

apple/container network is 192.168.64.0/24.

1. Pinging an adjacent local host in 192.168.0.0/24 from the host works. The packets go out of en0 with its IP (192.168.0.X).
2. Pinging a remote host running CF ZT WARP by its CGNAT IP 100.96.0.Y from the host works. The packets go out of utun4 with its IP (100.96.0.X).
3. Pinging a remote host running CF ZT WARP by its local IP in 192.168.1.0/24 from the host works. The packets go out of utun4 with its IP (100.96.0.X).
4. Pinging an adjacent local host in 192.168.0.0/24 from a container works. On the host the packets are visible on bridge100 with container IP (192.168.64.X), and then go out of en0 with its IP (192.168.0.X).

### Current behavior

5. Pinging a remote host running CF ZT WARP by its CGNAT IP 100.96.0.Y from a container does NOT work. On the host the outgoing packets are visible on bridge100 with container IP (192.168.64.X), and nowhere else (neither en0 nor utun4).
6. Pinging a remote host running CF ZT WARP by its local IP in 192.168.1.0/24 from a container does NOT works. On the host the outgoing packets are visible on bridge100 with container IP (192.168.64.X), and nowhere else (neither en0 nor utun4).

### Expected behavior

5. Pinging a remote host running CF ZT WARP by its CGNAT IP 100.96.0.Y from a container works. On the host the packets are visible on bridge100 with container IP (192.168.64.X), and then go out of utun4 with its IP (100.96.0.X).
6. Pinging a remote host running CF ZT WARP by its local IP in 192.168.1.0/24 from a container works. On the host the packets are visible on bridge100 with container IP (192.168.64.X), and then go out of utun4 with its IP (100.96.0.X).

### Environment

```markdown
- OS: 15.7.2 (24G325)
- Xcode: 26.2 (17C52)
- Container: container CLI version 0.7.1 (build: release, commit: 420be74)
```

### Relevant log output

```shell
N/A
```

### Code of Conduct

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

Start by reproducing the container-to-host routing cases using the listed bridge100, en0, and utun4 observations and routes. Trace the container networking and host-routing entry points to determine why traffic to 100.96.0.0/12 and 192.168.1.0/24 stops at bridge100; done means both destinations leave through utun4 as expected.

Written by the indexing model from the issue text.