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

SERVER:

• SERVER-134701 - [Disagg] Oplog truncation should happen in its own batch
• SERVER-134838 - [Disagg] Speed up oplog truncation application in PIT Restore
• SERVER-134612 - Oplog truncation re-walks every unreclaimed deleted page because each pass starts from a null lower bound
• SERVER-134492 - Improve per-marker overhead of oplog truncation logic
• SERVER-125068 - Remove featureFlagSizeBasedOplogTruncationForDisagg

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.