Context
The ASC fast truncate implementation cannot run 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 support 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 write‑conflict detection semantics have not been validated. In particular, we do not yet know whether the POC correctly detects conflicts for:

• Truncates overlapping uncommitted updates/inserts
• Updates/inserts overlapping uncommitted truncates
• Overlapping truncates (uncommitted/committed)
  All of the above when timestamps are involved (e.g., truncate vs. newer/older updates by timestamp)

If write‑conflict detection is incomplete or incorrect, standby fast truncate could allow conflicting operations to commit silently or generate spurious conflicts, leading to data inconsistency or availability issues relative to ASC behaviour.

This ticket closes that gap by validating and correcting the standby fast truncate POC’s write‑conflict detection semantics: reviewing how the truncate list participates in conflict checks (including timestamped scenarios), aligning behaviour with WT’s write‑conflict rules and ASC fast truncate semantics.

We need to add focused Python tests that cover all key write‑conflict patterns so regressions are caught early. Furthermore produce unit tests for the write conflict truncate detection logic.