[4lmighty]

Summary

• make default-constructed chan<T> represent a Go nil channel
• keep nil send/receive operations disabled in non-blocking Select and blocking when awaited
• make close(nil) panic with Go-compatible behavior
• preserve receive success status in recv_t
• implement the frozen Select::recv2<N>() accessor
• add focused conformance coverage for nil channels and two-value receives

Motivation

The Select translation surface is now canonical, but large-scale ports would still need disruptive follow-up changes if channel zero values and two-value receive status were not representable. Go channels have a meaningful nil zero value, and receive status must survive selection so case x, ok := <-ch can be translated without a second communication.

This PR closes those translation-facing representation gaps before real-world porting begins.

Scope

This does not attempt to solve stronger exactly-one arbitration for blocking Select or general Go zero-value construction. Closed channel zero values still use T{} for the currently supported representations; the broader zero-value abstraction remains separate work.

[4lmighty]

LGTM overall; I don't see a blocker. The nil-channel representation and Select recv2<N>() status preservation look consistent with the frozen translation surface, and Build/Style are green. One non-blocking follow-up: the PR now promises that directly awaited nil sends/receives block forever, but the new conformance coverage only exercises nil cases through try_index(). It would be worth adding focused coverage that a nil send/receive stays suspended while another scheduled action can still run, so the timer-based implementation is protected from regression.

[4lmighty]

Added focused coverage in 4f1c4e7 for directly awaited nil send/receive operations. The test verifies both operations remain suspended while unrelated scheduled work still runs, protecting the nil-blocking implementation from regression.

[4lmighty]

Re-review looks good. The optional coverage gap is addressed: direct nil send/receive awaits are now exercised and verified to stay suspended without blocking unrelated scheduled work. I don't see a new code blocker. CI is still running on this head, so LGTM pending green checks.