fix(docker): keep the admin api and postgres on loopback; only the gateway binds the bridge - #486

closes #268

on bare-metal linux, detect_bind_host picks the docker0 bridge ip and ONECLI_BIND_HOST feeds all three published ports — gateway (:10255), admin api (:10254) and postgres (:5432). the same setting that lets agent containers reach the gateway also publishes the admin api and the database on the docker bridge, where unrelated containers can read every agent token and secret metadata.

changes:

• split the bind per service. the admin api and postgres now bind 127.0.0.1 by default, reachable only from the host
• the gateway keeps ONECLI_BIND_HOST (the bridge ip on bare-metal linux), so agent containers still work
• new opt-in overrides for exposing them: ONECLI_APP_BIND_HOST (dashboard/remote access) and ONECLI_POSTGRES_BIND_HOST (psql)
• APP_URL follows the app bind so the advertised url matches what's actually listening; install.sh prints the correct dashboard url and documents the split

verification:

• docker compose config with ONECLI_BIND_HOST=172.17.0.1 resolves: 10254 -> 127.0.0.1, 10255 -> 172.17.0.1, 5432 -> 127.0.0.1
• bash -n scripts/install.sh passes
• no tests reference the compose file or install output

behavior note: operators who previously reached the dashboard via the lan/bridge ip need to set ONECLI_APP_BIND_HOST now — that's the exposure this closes. related: #228 (rootless containers can't reach the gateway on loopback) is a separate concern on the gateway side, untouched here.