chore: harden the skip-value allocation test against unrelated allocations

[kinyoklion]

TestReaderSkipValueAllocations failed once on the Windows / Go 1.25 / -race matrix cell (expected 0 allocations, measured 1) and passed on re-run. The test is sound about the reader — the fragility is in the measurement: testing.AllocsPerRun samples the process-global malloc counter, and with runs=1 the assertion is effectively "nothing anywhere in the process allocates during this window." GOMAXPROCS(1) serializes goroutines but does not stop them, so one timer fire, finalizer, or stray wakeup during the window reads as a failure — and the -race Windows cell has the longest window in the matrix.

The fix is one line: AllocsPerRun(1, ...) becomes AllocsPerRun(100, ...). The function divides the total malloc delta by runs with integer division, so up to 99 stray allocations across the window read as 0, while a genuine allocation in the code under test occurs in every run and still reads as ≥ 1. The test body is otherwise unchanged.

Verified: 20 consecutive runs green plus 5 under -race; with a deliberate allocation injected into the closure, the test still fails every time.

The v3 line's copy of this test has the same runs=1 pattern (with an easyjson-conditional expectation) and gets the same fix in #61.

---

Note

Overview
Hardens TestReaderSkipValueAllocations so flaky CI failures (e.g. Windows / Go 1.25 / -race) are less likely when unrelated process allocations bump testing.AllocsPerRun with a single run.

The measurement changes from AllocsPerRun(1, …) to AllocsPerRun(100, …), with comments explaining that the counter is process-global and integer-averaging tolerates sporadic timer/finalizer noise while still reporting ≥1 when the closure allocates every iteration. The skip-value exercise and 0 expected allocation assertion are unchanged.

^{Reviewed by Cursor Bugbot for commit 7fb41d9. Bugbot is set up for automated code reviews on this repo. Configure here.}