During the resharding verification process, the _verifyClonedCollection function performs an aggregation that fans out to every recipient shard. This aggregation reads per-donor document counts from config.localReshardingOperations.recipient.resumeData and uses these counts to verify that documentsCopied == documentsToCopy for each donor. However, this cross-shard aggregation is both architecturally inconsistent and inefficient.

The _transitionToApplying phase, the recipient shard already reads its own resume data locally (without requiring a network hop) to populate numDocumentsCloned. Instead of relying on cross-shard aggregation, the recipient shard could construct a per-donor map {donorShardId -> documentsCopied} using the same local data. This map could then be updated to the coordinator document as part of the standard state transition process.