The resharding oplog applier ($sort in resharding_donor_oplog_pipeline.cpp) and the resharding transactions cloner ($sort in resharding_txn_cloner.cpp) run memory-tracked blocking stages under an internal client, so they are sheddable by SERVER-130333 (disabled by default). Shedding them frees little memory (small, spillable per-batch sorts) but can stall or abort a critical rebalancing operation, so each should open its own LoadSheddingExemptionGuard.

analyzeShardKey's $group/$lookup metrics aggregation is deliberately left sheddable — it is heavy diagnostic work for which a retryable back-off is the right response.
 
There are two resharding $sorts. Exemption is done via marking an opCtx, so we have to consider which opCtx is being used in each case:

• The oplog applier (resharding_donor_oplog_pipeline.cpp) reads a local oplog-buffer collection via attachCursorSourceToPipelineForLocalRead, so its $sort executes locally under the same opCtx. A local `markOperationQueryMemorySheddingExempt` works there, and it should call it: shedding frees little memory (a small, spillable per-batch sort) but can stall a critical rebalancing step.
• The transactions cloner (resharding_txn_cloner.cpp) serializes its $sort into an aggregate that runs on the donor (runPipelineDirectlyOnSingleShard); the recipient only runs $mergeCursors. A local opCtx mark on the recipient cannot reach the donor-side sort, so it would exempt the wrong operation. The sort is also hinted on its sort key, so the donor should serve it from the index (non-blocking, not memory-tracked) and never shed it — likely no exemption is needed. If it ever were, it would have to be plumbed to the donor (e.g. a field on the aggregate request), which is out of scope here.