Fix: Bound local WebSocket connections and HTTP Upgrade timeout #421

Problem

The default local WebSocket server accepts TCP connections and immediately spawns a task for each connection before the HTTP Upgrade is completed.

The current implementation has two resource-management problems:

1. There is no application-level limit on the number of local WebSocket connection tasks.
2. accept_hdr_async has no timeout, so a client that opens a TCP connection but never completes the HTTP Upgrade can keep a task and socket open indefinitely.

Impact

A local client can consume daemon tasks and socket file descripters by:

• Opening mant TCP connections without sending HTTP headers.
• Sending and incomplete HTTP Upgrade request.
• Completing the Upgrade and keeping the connection open without sending the application handshake.

Expected behavior

The local WebSocket server should:

• Enforce a bounded number of active connections.
• Reject or close new connections when the connection is at limit.
• Apply a timeout to HTTP Upgrade phase.
• Release the connection slot when the connection closes or the Upgrade times out.

Reproduction

1. Start the local daemon.
2. Open a TCP connection to the WebSocket Port.
3. Do not send any data, or only send and incomplete HTTP Upgrade request.
4. Observe that the connection remains open beyond the existing application handshake timeout.

Notes

This issue covers the default local WebSocket implementation only.