Resolve sendData on 'finish' instead of 'close' (closes #18)
sendData was hanging in Linux namespace containers (e.g. Namespace.so
CI runners) because it resolved on the socket's 'close' event, which
requires both sides to half-close. Some container network stacks don't
reliably trigger the server's auto-half-close, so the client waits
forever for a FIN that never comes.
'finish' fires when socket.end() has flushed the writable side to the
kernel — for a fire-and-forget send over a Unix domain socket that's
exactly the right guarantee: the bytes are in the server's recv buffer,
which the kernel will hold until the server reads them regardless of
what happens to our userspace socket.
Only sendData had this bug. The other socket.on('close', ...) sites
(SessionConnection lifecycle, peekScreen safety net) are correctly
waiting for the full close signal.