security(ws): bound total concurrent WebSocket clients #369

Problem

On dborup/CoreScope master 1f423e0627976c961fb7a40f45016e817e582cc3, the existing webSocket limiter from PR #47 has a default concurrent per-IP cap of 0 (off) and no global concurrent-client ceiling. Its per-IP checks are skipped when clients arrive through an unconfigured reverse proxy because they cannot be distinguished safely. Each accepted /ws client owns a connection, goroutines and a 256-message send queue, so unlimited concurrent clients remain a resource-exhaustion path.

Reference: nashmesh/CoreScope PR 20 (reference only). Its implementation cannot be copied verbatim because our fork already has per-IP upgrade-rate limits, a deny list and its own webSocket configuration shape.

Requested change

• Add a nonzero, bounded global concurrent-client ceiling that remains effective even when per-client identity is unavailable behind a proxy.
• Preserve the existing per-IP rate limits, deny list and explicit trusted-proxy policy. Do not trust arbitrary X-Forwarded-For values.
• Reject excess clients before upgrading, provide an appropriate retry response, and release a reserved slot on failed upgrades, disconnect and hub shutdown.
• Document the default and any configuration option without changing WebSocket message semantics.

Acceptance

• Real-handshake tests demonstrate that only the configured number of clients can connect concurrently, including many connections through one proxy address.
• Failed upgrades and all close paths return their slots exactly once; race tests cover concurrent admission.
• Origin rejection and the existing deny/rate rules retain their intended precedence and behavior.
• Verify our Caddy/reverse-proxy topology before choosing any per-IP default.

This issue concerns repository behavior; it does not establish current production connection counts.