Summary

The WT-17841 fix relies on the ingest prune timestamp only advancing at checkpoint pickup, where the truncate list is pruned first. Nothing enforces that ordering, so it is fragile. Any path that advances the timestamp outside pickup would have to remember to prune the truncate list first, and the fix gives that no structural guarantee.

Current behaviour

• Checkpoint pickup prunes the truncate list, then publishes the ingest prune timestamp. That order is the only protection.
• WT-14916 tracks the limitation that the timestamp only advances at pickup. It will need to change, because the delay builds cache pressure.
• Two existing paths already sit outside the ordering. Sweep closes an idle ingest table against the connection's last checkpoint timestamp and ignores the per-table prune timestamp, so a truncate entry can outlive the ingest content it was masking and a re-inserted key reads as missing. This reproduces with aggressive sweep settings. Handle open sets the prune timestamp without pruning the truncate list, though that one is not reproduced.

Proposed solution

Enforce this where the ingest pruning actually happens, on the eviction side. Eviction would only discard ingest content that is covered by the prune timestamp once the truncate list has no surviving entry that could cover those keys. Then correctness would not depend on which code path advances the timestamp.