Currently, dbhash2.js tests dbhash commands against the config database, which makes it unable to run in a sharded suite because it has a step to drop collections in the config database which is not allowed via a router on sharded clusters. SERVER-83078 tried to work around this by making it test dbhash commands against a user database instead. But that led to some issues in the timeseries_crud_jscore_passthrough suite. In particular, the test failed this line for checking that the dbhash commands return the hashes for the test collections. That is, "foo" didn't show up in the "res.collections". From logging, it looks like "collections" contains hashes for "system.buckets.foo" and "system.views". It looks like this had to with how this suite has an override to turn every user collection into a timeseries collection (i.e. config database is excluded), and we should check the hashes for "system.buckets.foo" instead if the test is running in the timeseries_crud_jscore_passthrough suite.