CollectionCatalog::establishConsistentCollection (declared here) is meant to return a collection instance consistent with the currently open storage snapshot. Passing readTimestamp == boost::none instead means "use the latest collection instance," which is not guaranteed to be consistent with an already-open snapshot — this is the misuse pattern tracked generally in SERVER-133590.

Three timeseries catalog helpers had this bug: they run with a snapshot already open at a specific read timestamp (enforced via assertSnapshotOpen in two of the three cases) but call establishConsistentCollection with boost::none instead of the snapshot's actual read timestamp:

• checkTimeseriesUpgradeDowngrade in rename_collection.cpp
• timeseriesCollectionExistsInCatalog in catalog_helper.cpp
• collectionExistsInCatalog in catalog_helper.cpp

The fix retrieves the point-in-time read timestamp via getPointInTimeReadTimestamp() on the active recovery unit and passes it to establishConsistentCollection, matching the same fix previously applied to a similar call site in SERVER-123333.