fix(test): stop the serve tests racing on the shared log buffer

[vsolano9]

make cov fails on master roughly half the time. I hit it on #1097 and went looking for what I'd broken; it turned out to be already there, so here's the fix on its own.

Measured

Same command as the coverage job, go test -race -coverpkg=./... -coverprofile=c.out ./..., on clean master fbc8318:

Branch	DATA RACE
master (8 runs)	4
master (12 more runs)	7
this branch (12 runs)	0

Cause

Four serve tests capture log output the same way:

var logOutput bytes.Buffer
log.SetOutput(&logOutput)

log.SetOutput is process-wide, but the buffer is per-test, and three of the four tests are t.Parallel() — TestServeWithNoContentNegotiation, TestServeNegotiatingContent, TestServeHandlesConcurrentRequests. Go runs those together after the sequential tests finish, so they share whichever buffer was installed last. One test's request goroutines write into it through log.Printf while another reads it with String().

Every trace is the same shape:

Write at 0x00c0000d4540 by goroutine 474:
  bytes.(*Buffer).grow()
  log.(*Logger).output()
  github.com/goss-org/goss/outputs.logTrace()          traces.go:11
  github.com/goss-org/goss.healthHandler.ServeHTTP()   serve.go:93
  github.com/goss-org/goss.TestServeHandlesConcurrentRequests.func1()

Previous read at 0x00c0000d4540 by goroutine 452:
  bytes.(*Buffer).String()
  github.com/goss-org/goss.TestServeNegotiatingContent.func1()   serve_test.go:182

TestServeHandlesConcurrentRequests fires 16 concurrent requests, so it is usually the writer, but it isn't the culprit — it is doing exactly what it was added in #1092 to do. The shared buffer is the problem.

Fix

A mutex-guarded buffer, syncBuffer, in a new logbuffer_test.go. Test-only, no production code touched. The logger stays global and no test changes what it asserts — only the buffer becomes safe to touch from two goroutines.

What this deliberately does not fix

The routing is still wrong: a parallel test's log lines can land in another test's buffer. That is harmless today because the three parallel tests only t.Logf the buffer — the two tests that actually assert on it, TestServeCacheWithNoContentNegotiation and TestServeCacheNegotiatingContent, are sequential and finish before any parallel test starts.

Fixing it properly means giving each test its own logger, which means changing how outputs and serve get theirs. That is a real change to non-test code and it belongs in its own PR. Happy to do it if you want it.

One thing worth recording: in 24 runs of the full suite under -race, I saw TestServeCacheNegotiatingContent/immediately re-request but different accept header, cache should be warm fail once, asserting the cache was warm when the 100ms window had expired under race instrumentation. It did not reproduce in 12 further runs on either master or this branch, so it looks like a separate load-sensitive flake rather than anything to do with this change. Flagging it rather than quietly leaving it out.

AI assistance

This contribution was prepared with AI assistance. Every number above is from running the stated command locally, Go 1.26.5, macOS arm64.