Document how to Playwright-test a docker-compose stack running on the host from the firewalled agent

**What I'm trying to do:** bring up a **full multi-service application via `docker compose up`** in a workflow step (an nginx entry proxy fronting ~a dozen backend, database, and worker containers that talk to each other over the compose network), then have an agentic workflow's Playwright (CLI mode) browser drive the UI. Because it's a whole stack rather than a single dev server, it can't run inside the agent sandbox — it has to run on the host, and nginx is published on the runner's host port 80.

**Problem:** with the default agent firewall enabled, the browser can't reach the app by any address:
- `http://localhost/` → `net::ERR_CONNECTION_REFUSED` (localhost is the sandbox loopback, not the runner's host, so nothing is listening there)
- `http://host.docker.internal/` → Squid `503 ERR_DNS_FAIL` (the proxy can't resolve it)

A shell step on the runner reaches the app fine (`curl localhost:80` works), and the docs' visual-regression example works because its dev server and browser both run on the runner with no firewall between them. But that pattern doesn't apply to a host-booted **compose stack**, and there's no documented way to reach one from the firewalled agent.

**Questions:**
1. For a compose stack, is `network.topologyAttach` (with `network.isolation: true`) the intended mechanism — e.g. attach just the nginx entry container (which is dual-homed: reachable by the agent on `awf-net`, and proxying to the rest of the stack over its own compose network)? If so, what address does the browser then use to reach it, and could you add a minimal example? Does attaching a single compose-launched container by name work, and does it keep its original compose network?
2. If `topologyAttach` isn't the right tool here, what is the supported way? Must the firewall be disabled (`sandbox.agent: false`)? Are there safer options when the workflow runs **untrusted PR code** (where dropping the network trust boundary is a real concern)?
3. Could the Network / Playwright reference docs cover "reaching a multi-container stack running on the host" explicitly? "Spin up a docker-compose stack, then browser-test it" is a common CI shape, and today only in-process / in-sandbox servers are documented.

**Environment:** gh-aw v0.83.4, awf 0.27.42, GitHub-hosted `ubuntu` / `ubicloud` runners, `tools.playwright.mode: cli`, `sandbox.agent.sudo: true` (host-access mode).