SSE transport for environments that block WebSocket upgrades

chisel only speaks WebSocket today, so it can't connect through proxies or gateways that block or strip the Upgrade: websocket handshake (long-standing asks #24, #375; #507 is an example of chisel's transport blocked in the wild).

I've implemented an opt-in SSE+POST transport: a long-lived GET /sse for server→client, one POST /sse per client→server frame. It's --sse on the client, the server auto-accepts on /sse, and WebSocket stays the default. It reduces to a net.Conn behind the existing share/cnet seam (like conn_ws.go / conn_rwc.go), keeps chisel's single multiplexed SSH session, and adds no new dependencies (stdlib only).

I saw you built webdial with the same WS-primary / SSE+POST-fallback design. Would you prefer chisel's SSE built on webdial, or kept inline/stdlib? Happy to go either way; benchmarks and tests are ready.

Start by reviewing the share/cnet seam and the existing conn_ws.go and conn_rwc.go implementations, then trace the client --sse option and server /sse entry point. Compare the proposed inline stdlib approach with webdial, and use the mentioned benchmarks and tests to verify the transport while preserving WebSocket as the default.