lru: in jump-grow copy loop use peek instead get

[AskAlexSharov]

The migration copy in maybeGrow runs with resizeMu and every put stripe held, so its cost is a stall for all writers.

Keys() walks oldest-first, so the new generation's recency order comes from insertion order alone. Get additionally moves each entry to the head of the generation being retired — an unlink plus a relink over three random cache lines per entry, for nothing. Peek does the same lookup without the re-link.

Three copy loops: GenericCache, growLRU, tailLRU.

TestGenericCache_GrowCopyMatchesGetBasedCopy pins the equivalence on the production path: it drives a jump-grow cache and a fixed-capacity one through the identical insert/read sequence, stops the moment the first real grow fires, then rebuilds the copy the way the code read before this change (Get) into the geometry the grow chose. Keys, order, and values must match. Reversing the copy order or dropping one entry in maybeGrow both fail it.

Nothing in execution/cache or execution/commitment reads freelru's own Metrics() — the only behavioural difference between Get and Peek — and no LRU here sets a lifetime, so the shared findKey expiry path is inert.

[AskAlexSharov]

Merged the reworked base (#23522) in at 8773d7f5. The base absorbed half of this PR, so the content changed:

• GenericCache is done there now. Growth moved into shardedLRU, and migrateLocked already reads the retiring shard with Peek — plus it asserts the copy cannot evict. Nothing left for this PR to change on that path.
• What remains is growLRU.maybeGrow (grow_lru.go) and tailLRU.maybeGrow (branch_cache_tail.go), which still copy whole-cache with Get.
• TestGenericCache_GrowCopyMatchesGetBasedCopy no longer compiles against the new geometry (curCap/shardCount moved into shardedLRU), so it is retargeted at growLRU, where the copy loop it pins still exists: TestGrowLRU_GrowCopyMatchesGetBasedCopy in code_cache_concurrency_test.go.

./execution/cache and ./execution/commitment pass.