Summary: Follower truncate and a concurrent write to the same range can both commit

Problem

• __clayered_truncate_follower runs the range check, scans ingest, then appends its list entry; nothing is held across these steps.
• A concurrent writer runs __wt_layered_table_truncate_detect_write_conflict under the read lock, releases it, then writes to ingest.
• If the writer's check runs before the entry is appended and its ingest write lands after the scan passed the key, neither side conflicts.

Scenario

• Key K exists only in stable. T1 truncates [a, b] covering K; T2 inserts K in the window; T2 commits at 10, T1 at 20.
• Follower reads return K (ingest wins over the list) although a truncate covering K committed later.
• Step-up drains K@10 then replays the truncate @20 over it: K disappears on the new leader.
• Leader: __wti_delete_page holds the ref locked across its checks; T2 gets WT_ROLLBACK.

Definition of Done

• Either serialise the truncate's check-and-append against writers' check-and-write (lock or generation) or re-check the list after the ingest write and roll back on a hit.
• Python test with a timing-stress point in the window.

Notes

• Not a MongoDB use case (no concurrent writers on a range being truncated). The design called for blocking writers during the check.