benchmarking: walk RAM after resume (--mem-read) and rotate the churn window

[Lucky Abolorunke (Oneimu)]

What pr does

Makes resume measurements require the actor's memory to actually work: adds ReadRAM — a glutton request that walks the working set (reads one byte per 4KiB page across the requested size) before responding, plus a --mem-read knob so the benchmark cycle performs that walk right after every resume.

Today's cycle proves an actor is reachable after resume, not that its memory is usable: the ping answers without touching the working set. A real application must read its memory to serve requests. This matters for where restore optimization is headed — a lazy/on-demand restore would look great on a benchmark that never reads memory (resume returns fast, ping returns fast) while real first-requests would stall faulting pages back in. With the walk in the cycle, "resume + first response" includes the cost of making memory usable, however the restore path schedules that work: eager restore pays it during resume, lazy restore would pay it during the walk — either way the total is in the tracked numbers.

Also upgrades churn with WRITE_MODE_OVERWRITE_ROTATE: overwrite at a per-key cursor that advances past each write and wraps, so repeated churn walks the whole array over time instead of re-dirtying the same prefix every cycle.

How it works

• ReadRAM(key, size) walks the first size bytes (suffixed string, e.g. "1Gi"; empty walks the whole array) of a WriteRAM allocation, one byte per 4KiB page — the cheapest touch that forces every page resident. The response returns bytes walked plus an XOR checksum of the sampled bytes so the reads are observable and can't be elided.
• Cycle order: resume → fill (once) → walk → churn → ping → suspend. The walk runs before churn deliberately: it must read the memory as restored, not pages churn just rewrote; churn then re-dirties after, so the next snapshot still carries fresh pages.
• The walk reports as its own GluttonReadRAM stats row — it never pollutes ping or resume latencies. Today (eager restore) it reads warm memory in milliseconds; a jump in this row is the signal that restore work got deferred onto the request path.
• Config travels the established channel: --mem-read in the suite's locust flags: → /boomer-config → the Go worker, passed verbatim to the wire; glutton is the only parser. Empty = disabled; the tracked large-memory suites set it to the full target (walk everything — strongest signal, simplest story). Existing suites unchanged.

Testing

• go test -race across cmd/benchmarking/glutton and internal/benchmarking/boomer/...: PASS. New tests cover the walk's byte count and checksum, missing-key/bad-size errors, cycle call order (fill → read → churn with the right sizes and modes), rotate-mode cursor wrap, disabled-by-default, and walk-before-fill as a no-op.
• Cluster verification (microvm, 1Gi target, full walk):