test: fix a data race in the domain list test server

[patramsey]

CI's Test job went red on a docs-only PR (#23), with a race report rather than a failed assertion:

WARNING: DATA RACE
Previous write at 0x00c000138090 by goroutine 24:
  cmd/domain.domainServer.func1()
      cmd/domain/list_get_test.go:49
--- FAIL: TestDomainList_AllFetchesAllPages (0.00s)
    testing.go:1712: race detected during execution of test

Cause

domainServer's handler appended each request URL to a captured slice with no synchronization:

var received []string
srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
	received = append(received, r.URL.String())   // <- line 49

runList fetches pages 2..N concurrently through an errgroup with SetLimit(5), so that handler runs on several goroutines at once and two can append simultaneously. Concurrent unguarded append is a data race by definition, and the slice header write is what -race caught.

Not a product bug. The racing state is the test's own bookkeeping, not anything runList touches. The concurrent paging it exercises is deliberate and correct.

Fix

The append is mutex-guarded, and the recorder is returned as an accessor that takes the lock and returns a copy, rather than the raw *[]string it was before. The pointer form makes an unlocked read the path of least resistance at every call site; the accessor removes that option instead of relying on each caller to remember.

On verification — read this before approving

I could not reproduce this locally. With the mutex removed I ran 600 iterations (-count=200 across -cpu=1,2,4, and again under GOMAXPROCS=2) and never tripped the detector. The race needs two page requests genuinely in flight at once, and over loopback on a fast machine the first finishes before the second starts. The CI runner is slower and busier, so it interleaves.

So the evidence here is not a mutation test. It's the race detector's own stack trace naming this exact line and two httptest handler goroutines — which is conclusive about where the race is, and the fix guards precisely that. The meaningful confirmation is CI on this PR.

This has been failing intermittently on main all along; #23 is just where it surfaced. #24 passed twice with the same code, which is consistent with an intermittent race rather than anything either PR introduced.

Test plan

• go vet ./cmd/domain/ clean
• golangci-lint run — no issues
• go test -race -count=1 ./cmd/domain/ passing; 10 consecutive -race runs of TestDomainList clean
• Behavior unchanged — the same assertions run, reading through the accessor