Spawned from SERVER-119697 (finding 2 in the CAR investigation).

Problem

Several ShardingDDLCoordinator participant commands perform writes on an un-pinned AlternativeClientRegion opCtx. Because that opCtx does not carry the pinned OFCV, the resulting oplog entries have no versionContext, so secondaries fall back to their live global FCV when applying them.

Affected participant commands (at 93388c59):

• shardsvr_drop_database_participant_command.cpp#L79
• shardsvr_rename_collection_participant_command.cpp#L218 (unblock path)
• shardsvr_collmod_participant_command.cpp#L71
• shardsvr_participant_block_command.cpp#L137
• shardsvr_move_primary_enter_critical_section_command.cpp#L71
• shardsvr_move_primary_exit_critical_section_command.cpp#L65
• shardsvr_set_allow_chunk_operations_command.cpp#L133

Notes from discussion

No FCV-gated feature-flag check was found on these paths today (the only FCV-gated flag observed on the apply path was gFeatureFlagClusteredCollectionOplogApplyFastPath, which is low-level, default:false, and not hit by sharding-metadata collections), so nothing misbehaves right now. However, per the discussion in parent ticket (SERVER-119697) these are sub-operations whose new opCtxs do not outlive the parent, so it is preferable to proactively propagate the OFCV manually, similar to:
https://github.com/10gen/mongo/blob/43f00637e64144792c1f7cf65adbd9fa30075605/src/mongo/db/shard_role/ddl/clone_catalog_data_command.cpp#L172-L177

This is a stopgap until SPM-4434 fixes the root cause of new opCtxs losing the parent's context.

Scope

• Propagate the OFCV/VersionContext to the ACR opCtxs used by the participant commands listed above.