(See the writeup in the linked BF for the analysis and more details.)

In debug and sanitizer builds, CollectionCatalog::_instantiateCollectionIfTesting (introduced with SERVER-109829) creates a second WiredTigerRecordStore for a URI that already has a live one in the catalog, so that stale pointers into the previous CollectionImpl surface as crashes or sanitizer reports rather than silently returning wrong data. The second WTRS's constructor acquires its own SizeInfo via WiredTigerSizeStorer::load(). There's a narrow race with WiredTigerSizeStorer::flush(): when flush has swapped its in-memory buffer but not yet committed its WT transaction, that load returns a default-constructed SizeInfo{0, 0} instead of the one the live WTRS is using. The second WTRS's numRecords then diverges from the live one, and any find({}).count() that resolves to the second WTRS reads zero. In CI this breaks dbcheck_extra_index_keys.js