[catnap] Windows: connect incorrectly signals completion

Description

In catnap/socket.rs impl Socket method try_connect calls connect on the underlying socket2::Socket. The result handling code from this call treats the WSAEWOULDBLOCK error code as positive confirmation of connection. If the user then issues another operation on the socket prior to the connection completing, the user may see unpredictable behavior.

How to Reproduce

int qt;
assert(demi_connect(&qt, ...) == 0);
assert(demi_wait(&qr, qt, ...) == 0);
assert(demi_pop(&qt, ...) == 0);

demi_wait(&qr, qt, ...) == ?

The final demi_wait call may indicate WSAENOTCONN.

Expected Behavior

demi_wait should not indicate completion of a complete qt until the underlying connection is established. This likely requires the catnap backend to poll the completion state of the connection. An example can be found in socket2 internals: sys::poll_connect for the Windows target.

Related Issues

None

Start in catnap/socket.rs at impl Socket::try_connect and inspect how the underlying socket2::Socket connect result is handled on Windows. Compare the completion-state approach with socket2's Windows sys::poll_connect and reproduce the demi_connect, demi_wait, and demi_pop sequence. Done means demi_wait does not report completion until the underlying connection is established.