WebSocketServer (server-side TLS failures) produce zero application-visible logs while WebSocket client reports them via Error callback #593

Problem

When a TLS handshake fails before a WebSocket connection is established, the client reports it via setOnMessageCallback (WebSocketMessageType::Error), so applications can log it normally.

On the server, the same class of failure is not delivered to setOnClientMessageCallback. The library only calls internal logError(), which writes to stderr. In our deployment stderr is not part of the main application log stream, so operators see nothing useful on the server side when TLS fails.

Reproduction

1. Run a WebSocketServer with TLS enabled and setOnClientMessageCallback wired to the app logger.
2. Trigger a TLS failure (e.g. invalid CA, cert mismatch, bad client cert).
3. Client logs show TLS/connect errors via the Error callback.
4. Server application logs show nothing — no error, no rejected handshake, no client IP.

Expected

Server-side TLS accept/handshake failures should be observable by application code (callback or pluggable logger), similar to the client Error callback.

Actual

Failures are only emitted internally to stderr; the application callback is never invoked for pre-connection TLS errors.

Environment

• IXWebSocket version/commit: <fill in>
• TLS backend: OpenSSL
• OS: Linux