Problem

__wt_blkcache_read previously allocated a hardcoded 4KB scratch buffer before reading a compressed or encrypted block, forcing an expensive realloc on nearly every read (typical maxleafpage is 32KB) that serialized on tcmalloc's allocator spinlock under concurrency; this was fixed in WT-17097 by pre-sizing the buffer to btree->maxleafpage. That fix only touched __wt_blkcache_read — the sibling function __wt_blkcache_read_multi, used for disaggregated-storage reads (base image + deltas fetched from the page server), still allocates its four decrypt/decompress scratch buffers (etmp/ctmp) with size 0, hitting the identical realloc pattern, and compounding it further since each delta in a page gets its own decrypt/decompress pass.

Solution

Pre-size all four __wt_scr_alloc calls inside __wt_blkcache_read_multi to btree->maxleafpage, mirroring the WT-17097 fix exactly — same idiom, same reasoning, no other logic changes. btree is already in scope at each call site.