ShardingDDLCoordinator performs a noop retryable write with majority write concern to all participant shards on re-execution after stepdown. This aborts in-flight commands from the previous executions. The ConfigsvrCoordinator infrastructure lacks this pattern.

The two concrete implementations (SetClusterParameterCoordinator and SetUserWriteBlockModeCoordinator) do attach session info with an incremented txnNumber to outgoing commands, but they never send an explicit noop retryable write to participants before re-executing a phase.

This tickets aims to validate whether the current recovery behavior of these two coordinators is safe, or whether a noop retryable write fence is needed.