Issue Summary

__evict_page_victim_cache() in src/evict/evict_page.c stores a page's in-memory disk image (page->dsk) into the disaggregated (PALI) block cache on clean eviction. page->dsk is refreshed only when a page is instantiated (a read-in or split/rewrite). A page reconciled in place — e.g. by checkpoint — keeps a stale page->dsk while its block_meta advances to the newly written version. Caching such a page would pair old image bytes with new metadata (page_id / LSN / checksum) and serve a wrong image on read-back.

This cannot happen today: a reconciled page carries a non-zero rec_result and is routed to _evict_page_dirty_update, never the clean-eviction victim-cache path (_wt_page_evict_clean returns true only when modify == NULL or rec_result == 0). But nothing at the victim-cache call site documents this, so the safety is implicit and fragile to future changes.

Context

• Affected code: _evict_page_victim_cache, _evict_page_clean_update in src/evict/evict_page.c
• The load-bearing eligibility invariant lives in __wt_page_evict_clean (src/include/btree_inline.h)
• Raised during review: a concern that the victim cache might store a stale/older disk image

Proposed Solution

• Add a comment where page->dsk is read explaining why a stale image cannot reach the victim cache.
• Add an assertion guarding the invariant: WT_ASSERT(session, page->modify == NULL || page->modify->rec_result == 0);
• Evaluate WT_ASSERT_ALWAYS since a violation is silent cache corruption rather than a crash.

Definition of Done

• Comment and assertion added in __evict_page_victim_cache.
• Builds cleanly and dist/s_all passes (clang-format + comment style).
• Change reviewed and merged.