from_env() ignores CONTAINER_CONNECTION and silently uses the local socket

### Summary

`from_env()` does not consult `CONTAINER_CONNECTION`, which the `podman` CLI honours. The failure is silent: it connects to the local socket and returns entirely plausible data from the wrong machine.

### Reproducer

With a named connection to a remote host that has containers running, and a local socket that does not:

```
local socket, explicit -> 0 containers
explicit ssh client to the remote host -> 7 containers
from_env(), CONTAINER_CONNECTION= -> 0 containers <-- used the local socket
from_env(), CONTAINER_HOST= -> 7 containers <-- correct
```

Both machines ran podman 5.8.4, so the version string does not reveal the mistake either. `from_env()` reads `CONTAINER_HOST` / `DOCKER_HOST` but not `CONTAINER_CONNECTION`.

### Why it matters

The natural way to write a deployment tool is to reuse what the CLI uses:

```bash
export CONTAINER_CONNECTION=production
```

```python
client = podman.from_env() # silently the local machine
```

A tool written this way builds, cleans up and reports success against the wrong host. There is no error to notice.

### Expected

Either `from_env()` resolves `CONTAINER_CONNECTION` through `PodmanConfig.services`, or the docstring states plainly that it does not and points at `PodmanClient(connection=...)`.

### Environment

podman-py 5.6.0 (Fedora `python3-podman-5.6.0-4.fc44`), podman 5.8.4 client and server, rootless, Python 3.14. Re-checked against current `main` before filing.

Start with from_env() and inspect how it reads CONTAINER_HOST and DOCKER_HOST. Then read PodmanConfig.services and the PodmanClient(connection=...) path to determine the intended handling of CONTAINER_CONNECTION. Done means the environment variable is resolved as expected or the limitation is clearly documented, with coverage for the reported remote-versus-local behavior.

Written by the indexing model from the issue text.