We should not have populations with the same population set and number (rdfs label)

We need to ensure that records in Composer do not reuse the unique combination of population set & index.

There are two different IRIs for 3 pairs of senmot populations. These are actually coming from the exported sheet where one is using http://uri.interlex.org/uris/composer/ IRI and the other is using the http://uri.interlex.org/tgbugs/uris/readable/sparc-nlp/ IRI. We should be using http://uri.interlex.org/tgbugs/uris/readable/sparc-nlp/ for these. But it was hard for me to manually fix these since they are actually different populations with completely different pathways with the same rdfs:label (the Short Name in Composer/ the Subject column in the exported sheet). I am using this export: https://composer.scicrunch.io/media/exports/export_v5-2-0_2025-10-16_20-56-09.csv
First pair:
neuron type senmot 1.
hasComposerURI: https://composer.scicrunch.io/statement/222
neuron type senmot 1
hasComposerURI: https://composer.scicrunch.io/statement/502

Second pair:
neuron type senmot 2
hasComposerURI: https://composer.scicrunch.io/statement/223
neuron type senmot 2
hasComposerURI: https://composer.scicrunch.io/statement/503

Third pair:
neuron type senmot 3
hasComposerURI: https://composer.scicrunch.io/statement/224
neuron type senmot 3
hasComposerURI: https://composer.scicrunch.io/statement/501

It's confusing, but 222, 223, and 224 have incorrect rdfs labels. (they're actually senmot 21, 22, 23).
222 has the wrong rdfs label, and should be senmot 21 ; not senmot 1. Statement 222 should be deleted because 477 is the accurate senmot 21.
502 is the correct senmot 1.

223 has the wrong rdfs label, and should be deleted. The one that should be kept is 435 *; they are senmot 22
503 is the correct senmot 2.

224 has the wrong rdfs label, and should be deleted. The one that should be kept is 427; they are senmot 23
501 is the correct senmot 3

How did this occur on ingest? and how do we prohibit this from occurring again?