docs(web): from https the address must be wss://, and the server does not speak it

The page and the README told the reader that a ws:// address is blocked from
an https origin, and then gave them a ws:// address. improvise-ws-server has
no TLS at all -- no rustls, no native-tls, nothing -- so wss:// is not
obtainable from it and the documented pairing could not work from the
deployed site.

Both now say the address must be wss:// from the deployed page, that the
server speaks plain ws:// only so TLS has to be terminated in front of it,
and that the ws:// form works when the page is served over http://localhost.
The missing capability is filed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EoW5BB87ZZdm96SvBTWawH

README.md

@@ -207,9 +207,13 @@ document open in the TUI is shared — start the websocket server and pass
 cargo run -p improvise-ws-server -- examples/demo.improv --port 8787
 ```
 
-then reload with `?ws=ws://127.0.0.1:8787`. From an https origin a `ws://`
-address is blocked as mixed content, so that pairing is most easily done with
-the local page above.
+then reload with `?ws=ws://127.0.0.1:8787`.
+
+**That form works only from a page served over `http://localhost`.** From the
+deployed https page the address must be `wss://`, because a `ws://` one is
+blocked as mixed content — and `improvise-ws-server` speaks plain `ws://`
+only, so reaching it from https means terminating TLS in front of it (a
+reverse proxy or a tunnel). Native `wss://` is not implemented.
 
 Caveat worth stating plainly: **no line of the browser JavaScript has ever
 run.** There is no browser and no headless DOM in the development environment,