lru: slab-elements instead of grow

[AskAlexSharov]

freelru sizes its element array from capacity at construction, so a cache either pre-commits its whole ceiling or gets copied into a bigger table as it fills. That copy is what costs fenced=194.8ms at 1M entries on n5, with a 4,194,304-entry step still ahead of it.

It does not have to be that way. Element positions are dense and self-relative — pos := lru.len, and every stored index (buckets[b], nextBucket, prevBucket, next, prev, head) is an offset into the same array. So the array need not be contiguous: hold it as fixed 8192-entry slabs (~917 KB) appended on demand.

• Residency follows what is stored, not what is configured. An empty cache holds zero slabs.
• Capacity never needs a rehash, so there is no grow path at all: maybeGrow, the all-stripe fence, curCap and the generation swap are gone.
• Only the bucket index is sized up front, and it is 4 B per slot.

execution/cache/slablru is freelru's single LRU vendored (LGPL/Apache headers kept) with elements []element replaced by slabs [][]element plus an elem(pos) accessor and reserve(pos). Upstream's own test suite is vendored with it and passes unchanged — that is the correctness argument. TestSlabsGrowOnDemand pins the new property: zero slabs empty, one at 8192 entries, two at 8193, and every key still addressable across the boundary.

Two tests are deleted rather than adapted, because the code they guard no longer exists: TestGenericCache_PutIfAbsentDefersAcrossGrow and TestGenericCache_GrowMigrationLossless both pin hazards of the jump-grow generation swap. There is no migration and no swap on growth any more — the only remaining swap is Clear, which is a different, fenced path.

Known gap for review: envelope accounting still charges at construction as before and does not yet follow slab allocation. It should charge buckets up front and a slab as each is appended.

Alternative to #23546 and #23553, which keep the copy and make it cheaper. Independent of #23552.