Current behaviour

Layered primary and slow follower truncates rely on individual record/page conflict checks. Those checks do not protect every possible key between the resolved truncate endpoints.

For example, suppose a table contains keys 100 and 200, but no key 150. One transaction truncates [100, 200] while another inserts 150. The insert may escape conflict detection because there was no record at 150 for the truncate to check or delete.

An uncommitted insert can also be hidden from the truncate's visible-key scan. These cases can allow both transactions to succeed even though the inserted key lies inside the resolved truncate range.

The follower fast-truncate path uses a truncate list for range conflict detection. Primary and slow follower truncation do not participate in that mechanism.

Expected behaviour

Apply consistent range-conflict detection across layered primary and follower fast/slow modes.

• A point write within the resolved inclusive interval must conflict with a truncate that is uncommitted or committed but invisible to the writer.
• A truncate must detect preceding conflicting point writes within that interval, including inserts hidden from its visible-key scan.
• Same-transaction operations and operations outside the resolved interval remain permitted, subject to existing conflict rules.

Protection is limited to resolved endpoints. Empty ranges receive no range protection, and keys before the first resolved endpoint or after the last remain outside its protection.

Definition of Done

• Cover existing keys and missing keys between resolved endpoints, in both operation orders.
• Cover layered cursors and supported table wrappers.
• Verify same-transaction operations, disjoint ranges, and rollback.
• Ensure primary and slow-path conflict entries do not cause follower read masking or replay.
• Verify entry cleanup and behaviour across role transitions.

Related tickets: WT-17637, WT-18784, WT-18856.