Problem
The new standby fast truncate design tracks both uncommitted and committed truncates on the layered table dhandle, using in‑memory truncate state instead of writing fast‑truncate metadata directly to the stable table. This means the layered dhandle is now the source of truth for pending and recently committed truncate ranges in standby mode.

However, the WiredTiger sweep server can still sweep (close/evict) layered dhandles. If sweep drops a layered dhandle while it still owns truncate entries, we effectively discard truncate state that has not yet been fully reflected in the stable table or checkpoint history. That would manifest as data corruption: keys that should be considered truncated may remain visible, or truncate replay logic on step‑up/checkpoint pick‑up may miss required truncates because the associated truncate list was thrown away.

This ticket addresses that risk by:

• Investigating how the sweep server currently interacts with layered table dhandles that hold truncate state
• Creating a Python test that reproduces the scenario where a layered dhandle with active/visible truncates is swept, to confirm whether corruption can occur in practice
• If the investigation confirms the problem, updating sweep behaviour to prevent sweeping layered dhandles that still own truncate state (or otherwise guaranteeing truncate metadata is safely persisted/garbage‑collected before sweep)

so that standby fast truncate does not lose truncate state via sweep and cannot silently corrupt data.