If a user creates a key past the end of an FLCS table, a concurrent transaction that tries to truncate any part of the implicitly created key range would result in WT_ROLLBACK.

Steps to reproduce:

1. Create an FLCS table.
2. Begin a transaction and insert a key past the end of the range, e.g., 58.
3. Begin another transaction and truncate a part of the key range, e.g., 30 through 56. This results in a transaction conflict.

Here are the steps represented as a `test/model` workload:

create_table(1, table, r, 8t)
begin_transaction(1)
insert(1, 1, 58, 40)
begin_transaction(2)
truncate(1, 2, 30, 56)
commit_transaction(1, 93, 0)
commit_transaction(2, 88, 0)

This interaction should not constitute a transaction conflict because the inserted key in transaction 1 and the truncated range in transaction 2 are disjoint. In fact, there is no conflict when we run the same workload on the row store or the VLCS. Ideally, these semantics should be the same across all table types.

This ticket is somewhat reminiscent of WT-12971, which covers a similar issue with remove, but the proposed fix (which is approved but not yet merged) does not fix the issue for truncate.