Motivation

The cross-checkpoint shared disk image cache (WT_SHARED_DSK_CACHE) shares reconstructed disk images across btrees keyed only on (file ID, address cookie). A btree opened by a checkpoint cursor is a separate dhandle over the same file, so it resolves the same address cookies and can share cache entries with the normal btree. This is not safe: the two reconstruct full disk images from deltas differently.

Problem details

When flattening base image + deltas, {}page_read_build_full_disk_image _calls }}{{_time_window_clear_obsolete on every cell, stripping time windows that are "globally visible". Global visibility is relative to the session's transaction: a normal read checks against the live oldest timestamp, while a checkpoint-cursor read runs under WT_TXN_IS_CHECKPOINT and checks against the frozen checkpoint_oldest_timestamp, which can be older. The same base + deltas therefore flatten to different bytes, but the cache has one slot per cookie.

If the normal btree inserts its image first, a checkpoint reader between the checkpoint's oldest and a stripped timestamp gets silent wrong results:

• A start cleared to WT_TS_NONE makes a too-new version look visible — the reader returns it instead of descending into the HS checkpoint.
• A stop cleared to WT_TS_NONE makes a delete look eternal — the reader returns not-found for a value alive at its read timestamp.

The gating macros WT_DSK_CACHE_CAN_READ / WT_DSK_CACHE_CAN_WRITE (src/include/cache.h) check only the cache state and WT_BTREE_DISAGGREGATED; they do not exclude checkpoint dhandles.

Suggested approach

Add !WT_DHANDLE_IS_CHECKPOINT((btree)->dhandle) to both macros so checkpoint-opened btrees bypass the cache and fall back to private per-page disk images. 

Definition of done

• Checkpoint-cursor btrees neither read from nor insert into the shared disk image cache.
• A test on a standby with the cache active: live btree populates an entry, then a checkpoint cursor with debug.checkpoint_read_timestamp between the checkpoint's oldest and a stripped timestamp verifies correct visibility (value alive before its delete; older version fetched from the HS checkpoint).