Windows: re-arm on a read WouldBlock produces a spurious writable event

On the Windows AFD selector, a socket registered READABLE | WRITABLE emits a spurious writable event on every read.

After a read returns WouldBlock, IoSource::do_io reregisters the socket's full stored interest; set_event resets user_evts, re-adding POLL_SEND, and since the socket is writable the next AFD poll completes immediately with POLL_SEND. So each read attempt produces a WRITABLE event nothing asked for.

Impact. This livelocks a tokio reader driven from a non-runtime thread — the spurious writable bumps the readiness tick and invalidates the reader's clear_readiness, so poll_read spins. Verified repro (Hyper): tokio-rs/tokio#8054.

Fix direction. Re-arm only the direction that blocked ("only reregister read", from the tokio-rs/tokio#8054 discussion). The wrinkle: do_io is direction-blind — Read/Write call do_io(f) with an opaque closure — so narrowing the re-arm touches the public do_io/try_io surface, not just the AFD SockState. Design discussion on tokio-rs/tokio#8054.