Discovered while validating WT-16812. The in-memory truncate-list write-conflict detection on the follower has three correctness gaps, each of which can let conflicting operations commit silently or miss a real conflict.

Bugs

1. search_near ingest truncate misses uncommitted ingest updates

The follower truncate path positions via `search_near` before `_wt_range_truncate`. `search_near` is a read and does not trigger `wt_txn_update_check`, so write conflicts against uncommitted ingest updates in the truncate range are not detected. The fix belongs in `_wt_insert_truncate_entry`.

2. Using `__wt_txn_visible` alone yields false negatives

Conflict detection currently treats "not visible to my txn" as "uncommitted," skipping it. A committed truncate can be invisible to the current transaction purely because of read-timestamp differences — it is still a conflict. The visibility-only check needs to be replaced with a proper committed-vs-uncommitted check.

3. Overlapping truncates with no ingest content never conflict

Conflict detection is driven off ingest CRUD operations. When two transactions each issue a truncate over the same (or overlapping) range with no ingest content in the range, neither transaction triggers an ingest CRUD path, so no conflict is raised even though one transaction should roll back. Needs a write-conflict check inside `__txn_insert_truncate_entry_helper` when inserting into the truncate list.

Constraint

CRUD operations and truncates inside the same transaction must not self-conflict. Any fix for the above three must preserve this invariant.

Relation to WT-16812

WT-16812 covers broader validation and test coverage. This ticket carries the concrete fixes; test additions driven by those fixes should live under WT-16812 (or this ticket, depending on review preference).