This is chenhao.qu@mongodb.com's proposed fix from WT-18885 discussion.

Root cause

When every key on a page is deleted but the deletes are only saved as in-memory updates, reconciliation produces an empty image and doesn't write it. Instead it keeps the page pointing at its old block, which still holds the non-empty data. This was added in WT-18579, to satisfy the "no progress" check on forced eviction. Eviction then gives the empty in-memory image to the victim cache under that old block's identity. A later read hits the cache and gets an empty page where the stored page is non-empty, which trips the assertion.

The old block didn't need to be kept. Freeing it is a versioned discard in the page log, so older checkpoints and lagging followers keep reading the old version. The page would stay in memory with its restored deletes, and the next real write would allocate a new page id.

Fix

Count an empty result as progress when the previous reconciliation wasn't empty, and let reconciliation free the old block instead of skip-writing. A page that was already empty stays "no progress". The victim cache then never sees an empty image tied to a block with real data.

Once this lands nothing should be able to produce an empty standalone image, so the victim cache check added in WT-18885 should be turned into an assert.

Notes

This ticket was split out of WT-18885, which trips the empty-page assertion in __random_leaf_disk when the victim cache serves an empty skip-write image.
WT-18885 will land the defensive victim cache gate and carry the reproducer config in test/format/failure_configs/CONFIG.disagg.WT-18885; this ticket is the reconciliation-side root cause fix.

• The keep-the-block behavior came in with WT-18579, to satisfy the WT-16244 no-progress check on forced eviction. WT-18804 (orphaned write generations) and WT-18885 are both downstream of the retained empty image it introduced.