An antithesis BF caught a bug where after SERVER-126254 it is possible for fsyncLock to advance the primaries durableOpTime without persisting an oplogTruncateAfterPoint that covers the timestamp. Startup recovery truncates based on that truncateAfterPoint, so we can truncate something we claim is durable.

In the BF this resulted in a crash during rollback where the node was trying to rollback to before its commit point, so its possible this could have also caused data loss if not fixed.