Under precise checkpoint, eviction can reconcile a page using the published checkpoint snapshot, which lets __sync_checkpoint_can_skip() skip re-reconciling the page during checkpoint as the on-disk image eviction produced is what checkpoint would have written. WT-17681 

That skip is currently gated on __sync_page_image_durable which verifies every reconciliation product actually has a written block address. However non-disaggregated eviction can leave a page's content only in memory: update-restore and scrub evictions produce multi-block or replace results whose block_cookie is NULL, and a re-instantiated page keeps its address on the ref rather than in mod. Checkpoint must then write those pages itself to get valid addresses.

If non-disaggregated eviction made the same guarantee when precise checkpoint is enabled of always writing the blocks rather than deferring to checkpoint then it can also benefit from pages being skippable at checkpoint time, since today any evicted page with an unwritten block forces a checkpoint write even when eviction already reconciled it under the checkpoint snapshot.

Scope / open questions:

• Which eviction paths can leave unwritten blocks (update-restore, scrub, in-memory btrees) and whether each can be made to write unconditionally under precise checkpoint.
• Cost: forcing writes on scrub eviction may cause performance regressions