Fix UQUICConn.Close deadlock and report handshake errors in NextEvent

[ari-ahm]

Fixes #421.

UQUICConn (u_quic.go) mirrors QUICConn (quic.go), but two changes from the Go 1.26 QUIC handshake rework only made it into QUICConn:

• Close deadlock. quicWaitForSignal now always sends on signalc before it checks for cancellation, and QUICConn.Close receives that send before draining blockedc. UQUICConn.Close didn't, so closing a connection while the handshake was waiting for data hung forever (with the handshake mutex held). This adds the <-signalc receive, and checks ctx == nil for "never started" like QUICConn does.
• NextEvent never reported a failed handshake. QUICConn.NextEvent returns the handshake error once as a QUICErrorEvent; UQUICConn.NextEvent kept returning QUICNoEvent, so a TLS-level rejection looked like a stall. This copies the same block.

Both changes are line-for-line what QUICConn already does.

Tests

u_quic_test.go adds UQUICConn versions of TestQUICCanceledWaitingForData and TestQUICHandshakeError, each for HelloGolang and HelloCustom. The Close test fails after a 5 s timeout instead of hanging the test binary.

• Without this change: TestUQUICCanceledWaitingForData fails ("Close() deadlocked"), TestUQUICHandshakeError fails ("NextEvent() = 2, want QUICErrorEvent").
• With it: go test ./... passes, and go test -race -count=3 -run QUIC . passes.

Found while bumping uTLS in a project that uses apernet/quic-go's uTLS-based Chrome parrot: its QUIC tests hung in UQUICConn.Close. Thanks to @Capricornus007 for the analysis in #421; their suggestion of a test that checks quic.go and u_quic.go stay in sync isn't included here.

🤖 Generated with Claude Code