Fast truncate behaves differently depending on the node role and the shape of the truncate, and we have no written record of which MongoDB use case lands on which path. That makes it hard to tell whether a reported slowdown is a WiredTiger problem or a usage problem.

Enumerate the MongoDB callers of range truncate under disaggregated storage - point-in-time restore, size based oplog truncation, time based and TTL truncation, and anything behind featureFlagSizeBasedOplogTruncationForDisagg - and for each one record:

• which WiredTiger path it takes: leader truncating stable directly, follower building truncate list entries, or the slow per-record path
• whether the usage matches what the path is designed for

Then write the resulting contract into src/docs, covering the ban on truncate while a step down timestamp is set, the exclusion of prepared transactions, and the behavioural split between leader and follower.