Detect the port the app actually binds instead of only probing the configured $PORT

Miren injects $PORT (default 3000) and health-checks exactly that port for port_timeout (default 15s). If an app listens on a different port (e.g. hardcoded 8080) and ignores $PORT, the only signal is a generic port 3000 not reachable after 15s failure, after which the instance is killed. With a single-writer disk in the mix this snowballs badly (see MIR-1245). It bites people porting existing apps that hardcode a port; jobsv2 hit exactly this.

Ideas (pick one or layer them):

• Detect whichever port the container actually binds (inspect listening sockets in the netns) and route/health-check that, rather than only the configured one.
• When the configured port times out but some other port is listening, fail with a specific, actionable error: "app is listening on :8080 but Miren expects :3000 (set via $PORT or [services.web] port)." Turns a 15s mystery timeout into a one-line fix.
• Surface $PORT and the expected port more loudly in the language docs / Procfile defaults.

Repro: deploy a Go app that hardcodes :8080 with no port in app.toml; it fails the port health check and never becomes ready despite running fine.