When a $lookup targets a sharded timeseries view, the subpipeline may be dispatched to a different shard for view resolution (e.g. after movePrimary relocates system.views). The flag is per-node/in-memory only - if its local collection object never received extended range inserts, that shard can throw CommandOnShardedViewNotSupportedOnMongod with a ResolvedView that carries timeseriesUsesExtendedRange=false

The executing shard then rebuilds the subpipeline using this incorrect flag, enabling the BoundedSorter optimization. When the actual data contains pre-epoch or post-2038 dates, the sorter throws error 6369910.

To fix this:
In LookUpStage::buildPipelineFromViewDefinition, after creating the new ExpressionContext from the ResolvedView, check the local shard's Collection object for the buckets namespace. If it has requiresTimeseriesExtendedRangeSupport=true, propagate that to the ExpressionContext, overriding the incorrect value from the remote shard's ResolvedView.