SERVER-134239 makes atomic batched writes backfill prevOpTime on the first entry of each statement's applyOps, so the session history of a multi-statement retryable write can be walked across statements. The rollback path also walks prevOpTime and does not account for this new cross-statement link yet.

Two places in rollback consume it. _processRollbackOp walks the applyOps chain by following prevOpTime; with the backfill a statement's first entry now points at the previous statement's terminal, so the walk runs past this batch and into the previous statement (and fails with IncompleteTransactionHistory if that statement has already been truncated below the stable timestamp). _restoreTxnsTableEntryFromRetryableWrites, which rebuilds config.transactions after rollback, only recognizes top-level stmtId entries and kApplyOpsAppliedSeparately. An atomic applyOps entry has neither a top-level stmtId nor that multiOpType, so it is skipped and config.transactions is not restored to the preceding statement.

The effect is the same retryability corruption as SERVER-134239, reached through rollback instead of failover: config.transactions is left in the wrong state and a retry of an already-succeeded non-idempotent update re-executes.

Splitting this out because it is latent in SERVER-134239.