Summary

Fix a null pointer dereference crash in the inspector socket when writing to a connection that has already received EOF or encountered a protocol error.

Root Cause

There are two crash paths, both caused by tcp_ being null when dereferenced:

Path 1: Async write after EOF

1. uv_read_cb fires → WsHandler::OnEof() → tcp_.reset() (sets tcp_ to nullptr)
2. On a subsequent loop iteration, uv_async_t callback fires → RequestQueueData::DoDispatch() → InspectorSocket::Write() → WsHandler::Write() → ProtocolHandler::WriteRaw() → dereferences null tcp_

Path 2: Write triggered during OnData parsing

1. ParseWsFrames() encounters a compressed or error frame → calls OnEof() → tcp_.reset()
2. delegate()->OnWsFrame() callback triggers a write back to the client → WsHandler::Write() → ProtocolHandler::WriteRaw() → dereferences null tcp_

Both execute on the same libuv event loop thread (no multi-threading), so mutexes cannot help.

Crash signature (Windows x64)

EXCEPTION_ACCESS_VIOLATION_READ, fault addr 0x148
TcpHolder::WriteRaw [inspector_socket.cc:733]
WsHandler::Write    [inspector_socket.cc:406]
InspectorSocket::Write [inspector_socket.cc:819]

0x148 is the offset of TcpHolder::handler_ — confirms this == nullptr (i.e., tcp_ was null when dereferenced).

Fix

• WsHandler::OnData: stop the parsing loop when tcp_ becomes null mid-iteration
• WsHandler::Write: early return when tcp_ is null (avoids unnecessary frame encoding)
• ProtocolHandler::WriteRaw: defensive null guard covering all write paths

No resource leak: WriteRequest is only allocated inside TcpHolder::WriteRaw, which is never reached when tcp_ is null. The -1 return is consistent with uv_write failure semantics.

This is consistent with the existing pattern in WsHandler::Shutdown() which already checks if (tcp_) before use.

Fixes: #34833