Persistent caches in shared /tmp dirs silently turn A/B perf runs into cold-vs-warm

When benchmarking a remote helper that keeps a persistent on-disk cache (here an FSDB reader that writes per-file store/index files under /tmp/<user>-<tool>/index keyed by the file's path+inode+mtime), redirecting HOME to a scratch dir is not enough: the cache root ignored HOME, so the first run populated it and every later run was warm. The 'before' run looked 4x slower than the 'after' run for reasons unrelated to the code change. Fix: find the cache root (grep the helper for its *_DIR env override), point it at a per-test dir, delete it before each 'cold' run, and report cold and warm separately with the code under test as the only variable. Also check you didn't leave entries in the shared cache: compute the cache key the same way the tool does and remove only that entry.