fix: prevent goroutine leak on context-cancelled reads (contextutil + reader.ConnReadN)

[G360-Niek]

What

Fixes a goroutine leak on context-cancelled reads, at both layers involved.

1. contextutil.ExecFunc* — unbuffered result channel. ExecFunc, ExecFuncWithTwoReturns, and ExecFuncWithThreeReturns run fn in a goroutine and return via ctx.Done() when the context is cancelled before fn finishes. The worker then sends its result on an unbuffered channel that no longer has a receiver and blocks forever — one leaked goroutine per cancelled call. Buffering each result channel (cap 1) lets the worker always send and exit.

2. reader.ConnReadN — blocking read not interrupted on cancel. Even with (1), a context deadline can't interrupt a blocking socket Read, so a cancelled ConnReadN returned the context error while the read goroutine stayed parked in Read — leaking the goroutine and pinning the connection. When the reader supports deadlines (net.Conn and friends) it now expires the read deadline on cancellation so the read returns; the deferred stop leaves the deadline untouched when the read finishes in time. The post-cancel error is normalized to the context error so the existing "return partial data on timeout" handling is deterministic rather than racing the unblocked read. A connection whose read was cancelled is left with an expired deadline and should be discarded (documented on ConnReadN).

Proof (added regression tests)

• context/leak_test.go: 50 context-cancelled calls per ExecFunc* helper, asserting the goroutine count returns to baseline — fails on the unbuffered channels, passes with the fix.
• reader/conn_read_cancel_test.go: asserts ConnReadN leaks no goroutine on cancellation, and that partial data received before cancellation is returned rather than dropped.

Full context/ and reader/ suites and -race stay green.

Note

The residual case of a reader that blocks in Read yet exposes no SetReadDeadline cannot be interrupted by any of the above; ConnReadN still returns to the caller on cancel (that read goroutine is unavoidable for such readers). This targets net.Conn-style readers, which is ConnReadN's documented use.

Fixes #759