The test operationResponseMaxMS parameter returns multiple getMore responses with advancing PBRTs when the scan is interrupted fails intermittently, most visibly on the disaggregated-storage variant, with:

0 is not greater than 0 : PBRT must advance after a partial oplog scan

The first interrupted getMore returns docsExamined:1 and changeStreams.optime equal to the change stream's initial PBRT, so bsonWoCompare(pbrt1, initialPBRT) is 0 and the assertion fails.

Root cause. The change stream PBRT is derived from CollectionScan::_latestOplogEntryTimestamp, which advances only when the scan actually reads an oplog record. The operationResponseMaxMS interrupt is checked in the yield after doWork() returns and makes the executor return IS_EOF. The PBRT therefore advances only if the scan reads an entry with ts > initial before the deadline fires.
The old test blocked a single, fixed doWork() call using configureFailPoint(primary, "hangCollScanDoWork", {}, {skip: 1}) + pauseWhileSet. But hangCollScanDoWork is a global failpoint that fires on every collection scan, and the number of doWork() calls preceding the first post-resume oplog entry (cursor creation, oplog-visibility NEED_YIELD calls, and unrelated background collection scans such as QueryAnalysisWriter / config.* DDL) is non-deterministic.
On the disagg variant, extra warm-up doWork() calls consumed the single skip, so the blocked-then-interrupted doWork() read only the resume-boundary oplog entry (whose timestamp equals the initial PBRT). The operationResponseMaxMS deadline then fired before the scan advanced to any later entry, leaving the PBRT unchanged.