Only four connection level statistics exist for the layered truncate list today: search calls, search entries walked, GC runs, and GC entries removed. That is not enough to diagnose a truncate problem in the field - we cannot see how large the list is, how often entries are added or dropped, or whether truncate is causing write conflicts.

Work out which statistics are actually worth adding, then add them. Candidates to evaluate:

• entries inserted into the truncate list, and a current length and high water mark gauge
• entries removed by transaction rollback, and entries dropped when the list is cleared on ingest drain or step up - these are currently indistinguishable from GC removals
• read path hit versus miss on the truncate list search, so a miss that walks the whole list is visible
• a dedicated truncate write conflict counter. Both conflict sites bump the generic txn_update_conflict today, so conflicts caused by truncate are invisible
• per table attribution. Every layered truncate statistic is connection level, so a single hot table cannot be isolated

Weigh each candidate against its cost on the truncate hot path, since the search sits on every layered read and write. Statistics are defined in dist/stat_data.py, and the increment sites live in src/txn/txn_truncate.c and src/cursor/cur_layered.c.