Context: To avoid persisting metadata consistently, all feature flag checks inside ShardingDDLCoordinators must keep the same results through the execution of the DDL. We do this via OperationFCV (versionContext): We snapshot the FCV once at the beginning, persist it in the coordinator document, and propagate it to the phases and the participant commands.

Problem: It's somewhat common that ShardingDDLCoordinator phases and participants, create a new OperationContext via AlternativeClientRegion (example). This new OperationContext won't keep the OperationFCV (SERVER-108921), so it will check feature flags against the global ServerFCV which may have already transitioned and thus see different feature flags. SERVER-118777 is an example of a bug caused by this.

Proposal: Investigate current usages of AlternativeClientRegion in ShardingDDLCoordinator to confirm they don't check feature flags. If they do, we should propagate the OFCV (similar to the fix for SERVER-118777).