[matrixarkai]

The incremental-reclaim test wrote sixty-four entries with a forty-millisecond
life, recorded the memory figure as a peak, slept, wrote sixty-four more, and
asserted memory had not grown past that peak.

On a loaded machine the first loop took longer than forty milliseconds. The
earliest keys lapsed and were reclaimed while the rest were still being
written, so the peak was recorded at 832 bytes of the 4,096 the round
actually held — and the second round then read as growth:

memory grew past the first round despite the reclaim: 4096 vs 832

One failure in a six-hundred-test suite, green on its own three times in a row
immediately afterwards. The test failed for a reason that has nothing to do
with what it is about.

Two changes, and the second is the one that matters

The life is half a second and the sleep outlasts it, so the write loop has to
be an order of magnitude slower than it was before the fixture breaks.

And the precondition is asserted instead of assumed: nothing may have
lapsed when the peak is taken, and the peak has to account for every entry of
the round. A machine slow enough to break that now fails saying so, rather
than leaving a short peak to be read as growth at the end.

Planted

The condition is a machine slow enough that the round outlives the life it was
written with, so the plant slows the loop rather than shortening the life — a
life under a millisecond truncates to zero, which this cache reads as "no
expiry", and would have planted something else entirely.

With a one-millisecond life and two milliseconds between writes, the new
assertion fires:

entries lapsed while the first round was still being written, so the peak is not a peak

Green before the plant and green again after it, run on its own each time.

Gates on both feature arms: cargo fmt --check, clippy --all-targets -D warnings, both suites, the vocabulary check, and the allocation report with
--require-passed.

🤖 Generated with Claude Code