Address review of the audit fixes

A retry or redirect after an early answer to Expect: 100-continue now
opens a new connection, interim responses are also skipped while
waiting for 100 Continue, and a URL Client cannot use, such as one with
userinfo, gives an invalid client. Only a 407 is passed on from a
refused CONNECT, WebSocket::close() sends only a valid payload, and the
SSE client stops on an oversized event rather than reconnect to it.

Media type parameter names and user extension mappings are matched
without case, file content is read in larger chunks from a buffer of
its own, the streaming decompression limit reports
ExceedMaxPayloadSize, and the tests use the existing single-response
server helpers. Comments and the README are brought in line.

README-websocket.md

@@ -121,8 +121,6 @@ using SubProtocolSelector =
 
 The `SubProtocolSelector` receives the list of subprotocols proposed by the client (from the `Sec-WebSocket-Protocol` header) and returns the selected one. Return an empty string to decline all proposed subprotocols. A returned value that the client did not propose is ignored.
 
-The handler is called whatever the `Origin` of the handshake. A browser sends its cookies along with a WebSocket handshake that another site starts, so if cookies authenticate the connection, check `req.get_header_value("Origin")` against the origins you serve first (cross-site WebSocket hijacking).
-
 ### WebSocket (Server-side)
 
 Passed to the handler registered with `Server::WebSocket()`. The handler runs in a dedicated thread per connection.
@@ -360,6 +358,8 @@ svr.set_pre_request_handler([](const httplib::Request &req, httplib::Response &r
 });
 ```
 
+The server accepts a handshake from any `Origin`. A browser sends its cookies with a handshake another site starts, so if cookies authenticate the connection, also check `req.get_header_value("Origin")` against your own origins in one of these handlers (cross-site WebSocket hijacking).
+
 ### Custom Headers and Timeouts
 
 ```cpp