test: TestPrepareModernLayoutReusesBuffers flakes on process-wide allocation counters

[mykaul]

Problem

TestPrepareModernLayoutReusesBuffers/expanding compressed, multi segment flakes in the
full unit suite under -race with coverage:

frame_test.go:1496: segmenting a warmed-up framer allocated 2 times per request, want 0

Observed on PR #1082 "perf: locality- and RTT-aware write coalescing, with TLS support"
Code coverage. That PR does
not touch frame.go, frame_test.go or internal/segment/. A re-run of the same job on
the same commit passed.

Not reproducible locally: 8/8 full-suite runs green under the exact CI invocation
(go test -tags unit -timeout=5m -race ./... -cover -covermode=atomic -coverpkg=./...),
plus 6 concurrent instances under CPU contention. Green in isolation, repeatedly.

Root cause

Same family as #1027, but that issue's remedy does not apply here — this test never calls
t.Parallel().

testing.AllocsPerRun
brackets its loop with process-wide runtime.ReadMemStats counters, so any goroutine
still alive from an earlier test that allocates during the window is counted. The guard
asserts exact zero, so a single polluting goroutine trips it.

Two details make this subtest the most exposed one in the suite:

1. It is the largest case (5*segment.MaxPayloadSize - 1, ~640KB, five segments), so its
   21 iterations hold the measurement window open far longer than the other four subtests.
2. AllocsPerRun calls runtime.GOMAXPROCS(1) for the duration, so lingering goroutines
   are forced to interleave onto the same P as the code under measurement.

Note the reported value is quantised and does not imply a systematic 2-per-run leak:
AllocsPerRun returns float64(mallocs / uint64(runs)) — integer division before the
float conversion. A result of 2 means anywhere from 40 to 59 stray allocations across the
whole window, which is well within what one lingering goroutine can produce in ~50ms. It is
pollution, not a real regression in the segmentation path.

Impact

Unrelated PRs fail Code coverage, needing a manual re-run.

Proposed fix

Make the guard robust to process-wide pollution rather than asserting exact zero. Either:

• take the minimum of several AllocsPerRun samples (pollution can only add allocations, so
  the minimum converges on the true value), or
• assert a small bound rather than != 0, which keeps the regression it was written to catch
  (it guarded against allocating the whole wire output plus a temporary per segment, per
  request — orders of magnitude above any tolerance).

The first keeps the exact-zero intent. Worth applying to every AllocsPerRun/testing.Benchmark
based guard in the suite, not just this one, since #1027 showed the same failure mode in
policies_test.go and the fix there addressed only the parallelism half of the cause.