gcs: fix flaky test on bridge teardown race

[shreyanshjain7174]

Summary

TestGcsCreateProcess occasionally panics in CI with:

panic: Fail in goroutine after TestGcsCreateProcess has completed

The fake guest goroutine (simpleGcs) outlives the test and calls t.Error from a closed test scope. Observed flake rate locally: ~2/30 iterations; e.g. https://github.com/microsoft/hcsshim/actions/runs/26017233067/job/76470258316.

Root cause

bridge.Close() closes the underlying io.Pipe synchronously without a shutdown handshake. Because io.Pipe is unbuffered, a write of one bridge message arrives at the reader in two chunks (16-byte header, then body). If Close() lands between those chunks, simpleGcs's ReadFull(body) returns io.EOF after a partial read, which readMessage converts to io.ErrUnexpectedEOF (bridge.go:277). simpleGcsLoop only whitelisted io.EOF / io.ErrClosedPipe, so the error propagated into t.Error after the test had already returned — Go's testing framework then panics.

Fix

Two layered changes in internal/gcs/guestconnection_test.go:

1. simpleGcsLoop also treats io.ErrUnexpectedEOF as a benign teardown signal. The fake guest legitimately observes truncated frames when the bridge tears down abruptly; this is purely a test-side accommodation. Production behavior is unchanged — the real bridge still surfaces ErrUnexpectedEOF as a fatal protocol error via recvLoop → kill → ErrBridgeClosed.

2. connectGcs joins the simpleGcs goroutine via t.Cleanup. This ensures any future t.Error from background work (e.g. the inner io.Copy goroutine in the RPCExecuteProcess case has the same hazard) lands inside the test scope as a normal failure instead of panicking the runtime.