Detach Windows multiprocessing socket I/O during blocking calls - #9093

• This PR follows our AI policy.

Summary

Detach the VM thread around blocking Windows _multiprocessing.recv and _multiprocessing.send, following the existing socket I/O convention. These calls currently remain attached while waiting in Winsock, which can prevent stop-the-world collection from completing.

• Obtain an unlocked send buffer before detaching, so mutable-buffer locks are not held across the wait.
• Keep the buffer owner alive through reattachment.
• Convert the host-captured io::Error after reattachment instead of querying the thread's last error again.

This is a shared-main fix found while investigating #9088. The captured Windows stack stops in proxy finalization while waiting for a new manager authentication response. Missing detachment is a source-confirmed hazard consistent with that symptom; the capture does not establish the server's GC state or prove this is the exact cause of that hang.

Validation

• Independent ownership/source review and normal commit hooks passed.
• Linux stdlib threading compile-only check and strict Clippy passed (jobs1). These checks do not compile the Windows-conditional function bodies.
• Windows-specific compilation and existing canonical runtime coverage: pending hosted CI.
• No new remote-manager reproduction or concurrency/crash probe was run locally.

One production file; no Lib changes, skips, timeout changes, or test assertion changes.