External-device access broken: WebSocket server hardcoded to localhost on both ends

[petercorke]

Raised via review of #61 (community PR, closed -- see that PR for the
original report and repro).

The gap

SwiftServer (the static UI//retrieve/ HTTP server) already binds to
all interfaces (socketserver.ThreadingTCPServer(("", server_port), ...),
empty host = 0.0.0.0 equivalent) -- so the initial page load already
works from another device on the same LAN (e.g. a phone).

SwiftSocket (the WebSocket server) does not: it's hardcoded to
websockets.serve(self.serve, "localhost", port). Even if that's
rebound to 0.0.0.0, the frontend also hardcodes the connection
target client-side -- main.js: new WebSocketTransport(\ws://localhost:${portFromLocation()}/`)`.
A browser on another device would still try to reach its own loopback,
not the host machine, so the WebSocket connection would fail even
though the initial page loaded fine.

Both sides need to change together for external-device access to
actually work end-to-end:

1. SwiftSocket: bind to 0.0.0.0 (or "") instead of "localhost".
2. main.js: use window.location.hostname (or an explicit
   ws_host/similar query param, consistent with how socket_port is
   already passed through) instead of the hardcoded "localhost"
   string.

Not in scope here

#61's own diff bundled in a few unrelated/questionable changes not
carried forward: a 30-minute handshake timeout (up from 10s), an extra
positional constructor argument that doesn't match the current
SwiftServer signature, and an explicit allow_reuse_address (already
effectively covered today by the existing retry-on-next-port-number
loop in SwiftServer/SwiftSocket's bind loops).

Worth noting this is architecturally the same class of gap as the
Colab WebSocket-proxying issue (#45) -- "the HTTP page loads via one
mechanism, the WebSocket URL is never adjusted to match" -- just a LAN
scenario instead of a cloud-proxy one.