SERVER-60144 added functionality to check the shard version of a time series collection by assigning the bucket NamespaceString to the operation sharding state, however, in a read path the following interleaving might happen:

1. A sharded timeseries collection with namespace db.coll is created successfully
2. A read comes into the shard for the timeseries collection and the shard role is set in the OperationShardingState, notice that because it is a timeseries, the namespace is transformed from db.coll to db.system.buckets.coll
3. A drop collection and a shard collection gets executed, successfully dropping and creating a new sharded collection with namespace db.coll
4. The read path continues, selecting a filtering phase
5. When trying to obtain the ownership filter, we find that there is no shard version set for the collection db.coll in the operation context, so we fail the command with a tassert

Causing the read to fail. Usually on the find path, once it is detected the collection is actually a view (because timeseries collections are actually views), the read is transformed to an aggregation, but because a new sharded collection was created in step 3, the read continues as normal.

We should find a way to check the shard version in the read path, in order to determine whether the collection still exists before acquiring the lock free raii.