//! Host-side loopback listener for one bridged port, and the per-connection //! tunnel that carries its bytes into the container. //! //! ## Why not connect to the container's IP //! //! Container IPs are not routable from the host on Docker Desktop (macOS and //! Windows run the engine in a VM), so a host→`172.17.x.x` dial cannot be the //! transport. The Docker API is the only channel guaranteed to reach the //! container from the host, so each accepted connection is carried by a //! `docker exec` running `socat - TCP:127.0.0.1:`, with the exec's stdin //! and stdout wired to the TCP socket. `socat` ships in the container image. //! //! The exec plumbing itself is *not* reimplemented here: it comes from //! [`crate::docker::exec::create_attached_exec`], the same helper the //! interactive terminal sessions are built on. //! //! ## What the host listener is, and is not //! //! The listener is **not authenticated**, and cannot be. The port number is //! chosen by whatever CLI is logging in, the redirect URL is the provider's, and //! nothing in that chain can be taught to present a token — so there is no path //! token to add. Anything that can reach `127.0.0.1:` on this host reaches //! the container-side listener. That includes **any web page the user has open**, //! which can port-scan loopback from script. //! //! Two things narrow that, and neither is a substitute for the other: //! //! * The whole feature is opt-in per project, off by default, and only mirrors //! ports while its container is running. //! * [`web_request_verdict`] refuses the one case that is unambiguously a web //! page reaching in: a request whose fetch metadata says it is a cross-site //! **sub-resource** (`fetch`, `XMLHttpRequest`, ``, `