createIndexes can reply ok: 1 without having created the requested index. The client is
told the index exists, and any later operation on it fails with IndexNotFound for example.

How it happens

1. createIndexes resolves the target collection UUID and releases all locks, then blocks in the
   maxNumActiveUserIndexBuilds queue in IndexBuildsCoordinatorMongod::_startIndexBuild(). The
   config fuzzer had set the knob to 1, so the wait lasted ~15 seconds.
2. A concurrent moveCollection commits during that wait. Committing renames the temporary
   resharding collection over the original namespace, so the namespace survives with a new UUID (the
   reshardingUUID) and the UUID the queued build is pinned to no longer exists.
3. When a queue slot frees up, IndexBuildsCoordinator::_filterSpecsAndRegisterBuild() does
   AutoGetCollection(nssOrUuid, MODE_X), which cannot resolve the UUID and throws
   NamespaceNotFound.
4. runCreateIndexesWithCoordinator() catches NamespaceNotFound, treats it as "the collection
   was dropped, so there is nothing to do" (LOGV2 id 20448) and returns a success reply.
   The interpretation in step 4 is only valid when the collection was really dropped. Here the
   namespace still exists, holding a different collection that does not have the requested index.

Why the existing resharding guards do not fire

checkShardVersionOrThrow() and resharding::throwIfReshardingInProgress() live immediately
after the failing lookup in _filterSpecsAndRegisterBuild(), so the NamespaceNotFound is
raised before either runs. The resharding operation has also already completed and deregistered by
then, so ReshardCollectionInProgress would not be raised even if reached.