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

Problem

runTransactionOnShardingCatalog creates the opCtx that runs the caller-supplied transaction chain under an AlternativeClientRegion without propagating the OFCV:
https://github.com/10gen/mongo/blob/93388c59d7a0981dc04ee7c6414179e7a03bc0d9/src/mongo/db/global_catalog/ddl/sharding_ddl_util.cpp#L691-L701

Seven OFCV-pinned coordinators funnel their config-catalog transactions through this helper (directly, via removeCollAndChunksMetadataFromConfig, or via runTransactionWithStmtIdsOnShardingCatalog):

• DropDatabaseCoordinator
• RenameCollectionCoordinator (placement-history writes)
• TimeseriesUpgradeDowngradeCoordinator
• DropCollectionCoordinator
• UntrackUnsplittableCollectionCoordinator
• ConvertToCappedCoordinator
• CreateCollectionCoordinator

Notes from discussion

The transaction chains passed in today are pure CRUD with no flag checks, so nothing misbehaves currently. This is latent: any VersionContext-aware check added to a chain (or reached via txn_api internals) would silently fall back to global FCV (feature_flag.cpp#L81). A single ForwardableOperationMetadata(opCtx).setOn(newOpCtx) inside the helper would re-pin all seven coordinators at once.

Per the discussion in the original ticket, full OFCV propagation is historically quite involved and CRUD/TXN paths don't typically benefit from OFCV, so this is only worth doing if the fix stays trivial. Tracking separately as a cheap proactive hardening item.