Summary

WT-18550 stopped internal page-in from automatically dirtying the parent when reconstructing WT_REF_DELETED children, but only for a disaggregated btree read in the dedicated checkpoint-cleanup session. Trees on the standard (local) block manager keep the original behaviour: reading a fully deleted internal page dirties it even when no child deletion is globally visible, so checkpoint reconciles and rewrites the page for no progress, and the cycle repeats on the next cleanup pass.

The reviewer of PR #14629 asked for a separate ticket to enable the same suppression for non-disaggregated trees; a FIXME referencing this ticket should be added at __inmem_deleted_ref_should_dirty_parent().

Approach

• Drop the WT_BTREE_DISAGGREGATED condition from __inmem_deleted_ref_should_dirty_parent() in src/btree/bt_page.c so the checkpoint-cleanup session suppresses page-in dirtying for every btree.
• Confirm the per-child scan in src/btree/bt_sync_obsolete.c dirties the parent whenever a child is actually reclaimed, so local-block-manager cleanup still makes progress and still frees blocks.
• Check the interaction with the cursor walk skip in __wt_btcur_skip_page(): for a local block manager tree, reading an internal page in is currently what marks it dirty and triggers the reconciliation that frees deleted children's blocks, and the cleanup thread alone runs too rarely to bound the space held by a truncate-heavy workload. Establish that removing the page-in dirtying does not regress space reclamation before making the change.

Risk

Space reclamation on local block manager trees currently depends on the page-in dirtying side effect. Removing it without a compensating path could leave deleted blocks held until the next cleanup pass, or indefinitely. The change must be validated against a truncate-heavy workload measuring on-disk size over time.

Definition of done

• __inmem_deleted_ref_should_dirty_parent() no longer distinguishes disaggregated from local block manager trees, or the ticket is closed with a documented reason why the distinction must stay.
• Existing fast-truncate and checkpoint-cleanup tests pass on both storage types, with coverage that a no-progress cleanup pass leaves the internal page clean on a local block manager tree.