Context
The ASC fast truncate implementation cannot be used on standby nodes because it writes fast‑truncate metadata directly to the standby table, violating the core invariant that standby mode must not perform updates/inserts on the stable table. To enable fast truncate on standbys without breaking this invariant, we are adopting a new standby fast truncate design based on an in‑memory truncate list.

Problem
After WT‑15207, a simple POC truncate list exists on develop, but its interaction with WiredTiger’s transaction and timestamp visibility rules has not been validated. In particular, the current POC may mishandle how truncate ranges become visible (or remain invisible) across different transactions and read timestamps. If the truncate list does not precisely respect WT’s visibility semantics, standby nodes could:

• Hide keys that should remain visible to some readers
• Expose keys that should have been truncated
• Diverge from primary/ASC behaviour under mixed truncate and update workloads

This ticket closes that gap by validating and correcting the standby fast truncate truncate‑list behaviour with respect to WT transaction and timestamp visibility: reviewing the POC truncate structure against visibility rules, and adding targeted unit tests and Python tests that exercise key transaction/timestamp combinations so that visibility regressions are detected early.