SSRF_PROXY_ALLOW_PRIVATE_IPS / SSRF_PROXY_ALLOW_PRIVATE_DOMAINS set in envs/infrastructure/ssrf-proxy.env have no effect

### Self Checks

- [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542).
- [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general).
- [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/issues), including closed ones.
- [x] I confirm that I am using English to submit this report, otherwise it will be closed.
- [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
- [x] Please do not modify this template :) and fill in all the required fields.

### Dify version

Latest (the bug exists in the current `main` docker-compose configuration; present in recent releases as well)

### Cloud or Self Hosted

- [x] Self Hosted (Docker)

### Steps to reproduce

1. Copy `docker/envs/infrastructure/ssrf-proxy.env.example` to `docker/envs/infrastructure/ssrf-proxy.env`.
2. Set values in that file, e.g.:
```
SSRF_PROXY_ALLOW_PRIVATE_IPS=10.0.0.0/8
SSRF_PROXY_ALLOW_PRIVATE_DOMAINS=internal.example.com
```
3. Start the deployment: `docker compose up -d`.
4. Inspect what the `ssrf_proxy` container actually receives:
```
docker compose exec ssrf_proxy env | grep SSRF
docker compose logs ssrf_proxy | grep -i allow
```

### ✔️ Expected Behavior

The values configured in `docker/envs/infrastructure/ssrf-proxy.env` should take effect, so the allowlist written into the squid config (`dify_allowed_private_networks` / `dify_allowed_private_domains`) reflects them. Per the documented convention in `docker/README.md`:

> Docker Compose reads `envs/*.env` files when present, then reads `.env` last so values in `.env` take precedence.

So setting the variables in the root `.env` should still be able to override `envs/infrastructure/ssrf-proxy.env`.

### ❌ Actual Behavior

The `ssrf_proxy` service does not load `envs/infrastructure/ssrf-proxy.env` at all. The two variables are only wired via `environment:` interpolation (`${SSRF_PROXY_ALLOW_PRIVATE_IPS:-}`), which reads from the root `.env` only — edits to `envs/infrastructure/ssrf-proxy.env` are silently ignored.

Additionally, `dify-env-sync` strips these two variables from the root `.env` during upgrades (they live in the `envs/` category, not the root `.env.example`), so configuring them in `.env` does not survive an upgrade either. `envs/infrastructure/ssrf-proxy.env` is the natural home for them per the project's env-file design, but that path is currently broken.

Inspect the ssrf_proxy service configuration, docker/envs/infrastructure/ssrf-proxy.env, docker/README.md, and the dify-env-sync behavior. Reproduce with docker compose up -d and the provided env and log commands. Done means the configured variables reach the container, update the Squid allowlists, and retain the documented root .env precedence and upgrade behavior.

Written by the indexing model from the issue text.