fix(client): wake a blocked Windows recv on closeTraffic

On POSIX, shutdown(SHUT_RDWR) unblocks a recv() already in progress on
another thread, which is how closeTraffic() wakes a worker parked in recv
without releasing the fd. Winsock's shutdown(SD_BOTH) does not do this: an
already-blocked recv() stays parked until data arrives, the peer resets, or
the socket is closed. That left the QWP I/O worker stuck and failed
SocketTrafficShutdownTest.testPlainSocketShutdownWakesWindowsRecvAndRetainsFd
on the windows-msvc-2022-x64 job.

Cancel outstanding I/O on the socket handle with CancelIoEx before the
shutdown(). This wakes the blocked recv() while leaving the descriptor
allocated, so the fd is retained (no reuse race) until close() releases it,
matching the POSIX/macOS behaviour the sibling tests already rely on.
Net.shutdown() is only reached via PlainSocket.closeTraffic(), so no other
caller is affected.

Author: bluestreak01

core/src/main/c/windows/net.c

@@ -232,6 +232,14 @@ JNIEXPORT jint JNICALL Java_io_questdb_client_network_Net_configureNonBlocking
 
 JNIEXPORT jint JNICALL Java_io_questdb_client_network_Net_shutdown
         (JNIEnv *e, jclass cl, jint fd) {
+    // Unlike POSIX, a Winsock shutdown() does not unblock a recv() that is
+    // already in progress on another thread. Cancel any outstanding I/O on the
+    // handle first so a worker parked in a blocking recv() wakes up. CancelIoEx
+    // does not close the socket, so the descriptor stays allocated and the fd
+    // cannot be reused underneath the worker before close() releases it. A
+    // FALSE return with ERROR_NOT_FOUND (nothing was pending) is expected here
+    // and deliberately ignored.
+    CancelIoEx((HANDLE) (SOCKET) fd, NULL);
     const int result = shutdown((SOCKET) fd, SD_BOTH);
     if (result == SOCKET_ERROR) {
         const int error = WSAGetLastError();