Fix regenerator: repackaged jar's embedded Maven metadata misattributed to the artifact

[epugh]

Running regenerate_dependency_mappings.py reported 15 spurious conflicts for guava across Solr 8.1.0–8.7.0:

com.google.guava:guava @ 8.1.0..8.7.0: on file = '25.1-jre', resolved = '18.0'

The on-file 25.1-jre is correct. The images ship only guava-25.1-jre.jar in WEB-INF/lib; the 18.0 comes from carrot2-guava-18.0.jar (in the clustering contrib), a shaded repackaging of guava that still carries guava's META-INF/maven/com.google.guava/guava/pom.properties. syft therefore reports it as a standalone com.google.guava:guava@18.0 with virtualPath = '/carrot2-guava-18.0.jar' — no : nesting marker, so the existing "shaded inside another archive" filter (_is_standalone_jar) didn't catch it. The disagreement range (8.1.0–8.7.0) matches exactly where carrot2-guava is bundled (it's removed in 8.8.0+, and tracked separately as org.carrot2.shaded:carrot2-guava).

Fix: require the on-disk jar filename to start with the purl's artifact (<artifact>-), so a differently-named repackaged jar can't masquerade as the artifact whose pom.properties it happens to carry. A genuine standalone jar is named <artifactId>-<version>[-classifier].jar, so guava-25.1-jre.jar is kept while carrot2-guava-18.0.jar (and junit4-ant's embedded guava) are dropped. The :-nesting check and the older-syft fallback are preserved.

Verified by syft-scanning guava-25.1-jre.jar and carrot2-guava-18.0.jar together: the updated iter_maven_packages yields only com.google.guava:guava@25.1-jre.

Data-only change is not needed — the map's 25.1-jre values were already right; this just stops the regenerator from flagging them as false conflicts. (solr-dependency-versions.json is untouched here.)