On the authoritative shard-metadata path, refineCollectionShardKey only installs the post-DDL catalog/metadata on shards that own chunks of the new routing table. If the DB primary owns no chunks, its in-memory CSR and durable shard catalog stay at the pre-DDL shard version.

This is a problem for various reasons:

• checkShardFilteringMetadata flags the divergence between the global and the shard catalog.
• If refine is transforming the collection metadata from non-authoritative to shard-authoritative, the primary may continue thinking that the collection is untracked when this is not true.