The check to see if a shardFilter should be added uses OperationShardingState::isComingFromRouter(opCtx) https://github.com/10gen/mongo/blob/98db178064e87100e77e0de49346ea43af01a702/src/mongo/db/query/get_executor.cpp#L1318-L1321.  However, the OperationShardingState information is not always present in the opCtx as it is not persisted across getMore's. This causes issues for queries that originally come from a router, but are now performing local reads (a new scenario from SERVER-111401*).

The check could potentially be changed to use CollectionAcquisition::getShardingDesription().isSharded() instead as the collectionAcquisition already contains all the routing information necessary to determine if the shard filter should be applied. It may also be better from a CAR perspective if the query layer uses the collectionAcquisition instead. 

However, this change should be done with care and be investigated to confirm it will work equivalently to OperationShardingState::isComingFromRouter(opCtx). 

*SERVER-111401 adds the ability for idLookup to reuse a collectionAcquisition across new pipelines as local reads but the original query could be from a router. In order to enforce a shardFilterer is added correctly, the shardRole is set before pipeline preparation using information from the collectionAcquisition. This workaround would be unnecessary if the check is changed. See https://app.graphite.com/github/pr/10gen/mongo/43624/SERVER-111401-InternalSearchIdLookup-uses-ShardRoleAPI-to-execute-queries#comment-PRRC_kwDOADUBOM6VFgNZ for more context.