fix: address issues found in end-to-end verification

Chained defects made the kagane browser-fetch path completely non-functional
in Docker Compose: headless-shell's compose command re-declared
--remote-debugging-port, colliding with the image's own entrypoint/socat
proxy (EOF on every dial); the sidecar was then only reachable by Docker DNS
name, which Chrome's DevTools HTTP handler rejects with a 500
(Host-header/DNS-rebinding check); and NewBrowserFetcher's NoModifyURL option
skipped /json/version discovery entirely, dialing a bare host:port that
Chrome 404s since /devtools/browser/<uuid> is minted fresh per Chrome start.
Fixed by trimming the redundant command flags, pinning headless-shell to a
static IP so BROWSER_WS_URL can name it directly, and removing NoModifyURL so
chromedp's discovery (which echoes the request's Host back into
webSocketDebuggerUrl) does the right thing on its own.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docker-compose.prod.yml

@@ -18,7 +18,10 @@ services:
     # Traffic arrives over the Traefik network, not a published port.
     ports: !reset []
     environment:
-      BROWSER_WS_URL: ${BROWSER_WS_URL:-ws://headless-shell:9222}
+      # Must be an IP, not the DNS name — see the base file's comment on this
+      # same key: Chrome's DevTools HTTP handler 500s any Host header that
+      # isn't an IP or "localhost".
+      BROWSER_WS_URL: ${BROWSER_WS_URL:-ws://172.28.0.10:9222}
     depends_on:
       - headless-shell
     # `networks:` here replaces the base file's list entirely, so both must be