Memory-per-client benchmarks: check that the reader releases what each request loaded

In a multi-client read benchmark (N concurrent agents, each issuing random queries against a large file), one format's per-client memory came out about 7x higher than expected. That made it look like only ~17 clients fit on a 256 GB box.

The cause was the benchmark driver, not the format. The adapter for that reader loaded each newly-touched signal or column on first use and never unloaded or freed it. Each client touched ~500 random items over its plan, so it ended up holding all of them. The other formats' adapters kept nothing resident, so the comparison wasn't like-for-like.

Checks before trusting a memory-per-client number: - Compare against a single-client run with a tiny working set. If memory scales with plan length rather than request size, something is accumulating. - Give every adapter the same lifetime policy: load-per-request with explicit release, or load-and-keep, and label which one was used. - Measure PSS/RSS mid-plan and at the end. Steady growth means a cache or leak. - Sanity-check against any earlier measurement of the same reader with a known working set.