[RanaPriyansh]

Revives the Apple completion check from #669 for #652, with additional validation.

On Apple targets, continue through the existing completion poll after connect succeeds. Keep immediate success on other targets. Extend the loopback test to check IPv4 and IPv6 peer identity, accepted data, and blocking-mode restoration. The IPv6 loopback check skips Redox and Vita.

A private syscall-interposition probe calls the public API: baseline returns Ok without polling; candidate returns TimedOut after one target poll. Both pass a non-target loopback transfer. This checks dispatch; the reported VPN setup was not reproduced.

The default cargo test --all-features command failed on both baseline and candidate because existing qnx cfg diagnostics are denied during tests. Successful local macOS checks declared this existing cfg with --check-cfg=cfg(target_os,values("qnx")). Blocking mode was observed only on local macOS. The local checks do not establish other-platform runtime behavior or the reported VPN configuration. All 58 reported hosted checks passed on prior head 9a39af9efbb9f1c38c47d5aacec7f570a12ac3d3 in CI run 39505258595. That head predates this comment-only follow-up. Cross-target compilation does not establish runtime execution on each target.

Codex used.

[chansuke]

could we keep the comment from #669 explaining why this exists? without it, Ok(()) falling through to poll looks like a bug imho

[RanaPriyansh]

Thanks for raising this. I restored the rationale from #669 above the Apple-specific path: a successful non-blocking connect can precede completion, so Apple targets continue to poll_connect. This change restores the comment only and adds no runtime evidence.

Codex used.