WriteUnitOfWork::getGroupType in src/mongo/db/storage/write_unit_of_work.cpp auto-upgrades a default kDontGroup top-level WUOW to kGroupForPossiblyRetryableOperations when primary-driven index builds are enabled. Today it consults only gFeatureFlagPrimaryDrivenIndexBuilds.isEnabledUseLastLTSFCVWhenUninitialized. It does not consult PersistenceProvider::mustUsePrimaryDrivenIndexBuilds(), so storage configurations that require primary-driven index builds at the provider level miss the auto-upgrade during an FCV transition window. A default-constructed multi-write WUOW under those conditions would trip WT's multi-timestamp constraint at commit.

Why this is split from SERVER-124383: routing this site through index_builds::primary_driven::isEnabled introduces a dependency cycle. write_unit_of_work is reachable from service_context, and the utility transitively depends on rss::ReplicatedStorageService which depends on service_context. Breaking the cycle needs either restructuring the utility's deps or injecting a provider-check callback registered at startup from outside write_unit_of_work's dep graph – both bigger than a bug-fix-sized change. SERVER-124383 worked around the symptom at the one currently-exercised callsite (BulkBuilderImpl::commit) by passing the group type explicitly, so no current caller relies on this path's auto-upgrade. Any future multi-write-per-WUOW caller that omits the explicit group type would reintroduce the WT multi-timestamp fassert.