The MaxKey orphan delete-guard (SERVER-130180, `featureFlagMaxKeyOrphanGuard`, on by default) lazily classifies range-deletion tasks the first time the ready-range-deletions processor dequeues a task in a term, upserting a state document into `config.maxKeyOrphanScanState` and implicitly creating that collection. In `magic_restore_selective_pit_sharded.js` the two setup moveChunks queue range-deletion tasks on the donor shard, so this write races with the backup cursor's checkpoint timestamp. When it lands after the checkpoint, the two extra oplog entries (collection create + state-doc insert) trip the exact-count assertion on `filteredEntriesAfterBackup` (`expected 10 to equal 8`, BF-44774).

SERVER-131529 extended the oplog-entry filter to cover these writes in three sibling tests but missed this one. Apply the identical filter extension here. The filter only feeds the count assertion, the entries passed into magic restore are unchanged.