test(wal): wait for async writes instead of racing the writer goroutine

[xe-nvdk]

Follow-up to #565, where I flagged TestPurgeInactive_ConcurrentWithWrite failing under Linux containers.

It is a test bug, not a product bug — and not flaky

I measured it rather than assuming:

Platform	Result
Linux (container), 20 runs	19 failures
macOS, 20 runs	0 failures

Nearly deterministic on Linux. "Flaky" was the wrong label — the test relies on a race the writer goroutine has no particular reason to win, and macOS's scheduler simply happens to let it.

Root cause

Append is asynchronous. It enqueues onto entryChan and returns (wal.go:444-453); a background writer goroutine performs the file write and only then increments TotalEntries (wal.go:300).

The test closed its producer channel once the 100 Append calls had been enqueued, then immediately asserted TotalEntries != 0. <-done says nothing about whether the writer ran.

I instrumented the actual values to confirm rather than infer:

TotalEntries immediately after <-done: 0
DroppedEntries:                        0
TotalEntries after 300ms settle:       100

Nothing was dropped and every entry was written. The WAL behaved correctly throughout; the test just looked too early.

Fix

Added waitForEntries, which polls until the writer has durably recorded the entries, or fails after 5s with a diagnostic (TotalEntries=… dropped=…) so a future failure says why.

Also replaced two fixed time.Sleep(50 * time.Millisecond) calls in TestPurgeInactive_ActiveFileNotDeleted. Those have the identical fragility with a larger margin — a fixed sleep only sets how often the race is lost, and on a loaded CI box or a slow container it can be lost too.

Verification

	before	after
TestPurgeInactive_ConcurrentWithWrite, Linux ×20	19 FAIL	0 FAIL
Full WAL suite, Linux container	FAIL	PASS (first time)
Full WAL suite, darwin	PASS	PASS
darwin -race ×10	PASS	PASS

Test-only change — one file, no product code touched, so no release-notes entry.

Note the cross-compiled -race binary can't be built here (needs a Linux C toolchain), so the container runs are non-race builds. Darwin -race covers the detector side.