The TransactionCoordinatorService will create its _catalogAndScheduler, with an invariant that it doesn't already exist, when stepping up or during sharding initialization as a primary.

However, if a secondary initiates a priority takeover and replicates the ShardingIdentity document from addShard as part of primary catch-up, it's possible that:

• Sharding initialization begins after the node is already primary according to this check.
• The TransactionCoordinatorService creates its _catalogAndScheduler.
• Sharding initialization completes.
• Replication invokes the _shardingOnTransitionToPrimaryHook and sees that sharding is already initialized.
• TransactionCoordinatorService::onStepUp tries to create the _catalogAndScheduler again, and triggers the invariant.