Query-memory load shedding currently determines shed eligibility from isFromUserConnection() || OperationShardingState::shouldBeTreatedAsFromRouter(), but when the merging pipeline of a sharded aggregation runs on a merging shard (rather than on mongos), it is dispatched with a leading $mergeCursors and carries no shard/database version, so shouldBeTreatedAsFromRouter() returns false and a memory-heavy blocking merge stage running on a data-bearing merging shard is treated as ineligible and never shed. This is a safe-by-default gap (the heavy work is usually pushed to the shards part, which remains eligible) but leaves a hole for pipelines whose blocking $group/$sort/etc. cannot be pushed down. Close it by marking the merge pipeline eligible via the existing merge-detection path (Pipeline::isMergePipeline() / the _treatAsFromRouter flag that view resolution already sets for the merge), so the merge phase on a data-bearing shard becomes sheddable.

I think the key examples of merge-on-shard (and thus the shedding gaps) are $percentile/$median and heavy $setWindowFields/$bucketAuto.