Several internal shardsvr commands persist authoritative shard catalog metadata by calling shard_catalog_commit helpers on a new OperationContext created via AlternativeClientRegion.

When execution control deprioritization is enabled, that alternative opCtx does not inherit the parent command's admission-control task type. Under load, the shard catalog commit work can therefore be deprioritized, delaying the commit of the shard catalog, which is holding the critical section blocking reads and writes.

For each affected command, after creating the alternative opCtx, we should add:

admission::execution_control::ScopedTaskTypeNonDeprioritizable deprioGuard(newOpCtx.get());

Affected commands: