Under kGroupForPossiblyRetryableOperations, a batched write that exceeds the per-applyOps size or count limit is packed into a chain of multiple applyOps oplog entries. Each entry is applied independently on secondaries (distinct optime / recovery unit), so a set of operations that must commit together cannot be allowed to straddle an entry boundary.

Introduce a notion of an atomic op group: operations tagged with a shared atomicGroupId must be packed into the same applyOps entry. Make the packer group-aware:

• when packing under kGroupForPossiblyRetryableOperations, never let an entry boundary fall inside an atomicGroupId run — roll an incomplete run wholly into the next entry;
• if a single group cannot fit one applyOps entry, surface it (ApplyOpsInfo::hasOversizedAtomicGroup) so the caller can decide how to handle it (e.g. escalate to an atomic-apply chain);
• operations with no atomicGroupId remain freely splittable.

Add TransactionOperations::sortByAtomicGroupId() so a caller that stages a group's operations non-contiguously can make them contiguous before packing.