During setFCV upgrade or downgrade, the finalizeUpgrade/finalizeDowngrade phase drops the authoritative database collection on each shard by UUID. If a primary step-down occurs, the phase may be retried by a new primary, causing a second dropCollection by UUID. The first drop succeeds, but the retry fails with CollectionUUIDMismatch because the collection no longer exists.

This ticket proposes to safely swallow CollectionUUIDMismatch in this context to make the drop operation idempotent and avoid unnecessary failures during FCV upgrade or downgrade.