Fix nil pointer dereference in Windows pipe writer Close

[mrafi97]

What does this PR do?

Adds a nil guard to pipeWriter.Close() on Windows.

newWindowsPipeWriter deliberately defers connection setup to the first
write, so conn is nil until then. Closing a client that never wrote
dereferenced that nil connection and panicked. udsWriter.Close()
already has this exact guard; this brings the pipe writer in line.

The connection is now read under p.mu rather than directly, because
Write() nils the field out under a write lock when a non-temporary
error disconnects it — an unsynchronized read in Close() is a data
race.

Motivation

#incident-59243
https://datadoghq.atlassian.net/browse/WINA-3031

Found via a crashing Windows service in datadog-agent. Its pre-flight
mode component dials the named pipe once to probe readiness, then the
statsd client dials again on first write. When that second dial loses a
startup race, the deferred client.Close() took down the process with
0xc0000005 — a read of address 0x18, i.e. a method call through a
nil interface.

Not a recent regression: conn: nil dates to c995f1b (March 2021,
first released in v4.5.0), and pipe_windows.go is byte-identical
between v5.8.3 and v5.9.0. It had simply never had a caller that closes
a client which never successfully wrote.

Testing

Adds TestPipeWriterCloseWithoutWrite, which constructs a writer and
closes it without writing — this panics on the current code. Verified
go vet and a test binary build under GOOS=windows; the pipe tests
themselves need a real Windows named pipe, so they only execute on a
Windows runner.

[datadog-prod-us1-6]

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 84.95% (+0.25%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: c3f1f6e | Docs | Datadog PR Page | Give us feedback!}