We made a first attempt to solve the issue where CMC can target a secondary node whose ShardingState is not yet initialized (SERVER-132376), but that only reduced the likelihood of it happening — there is still a race where the error can bubble up.

Waiting on ShardingState::awaitClusterRoleRecovery is not enough to guarantee that subsequent accesses to ShardingState are safe: there's a tiny race where, even after waiting, the ShardingState is not yet ready.