fix(java): use the OSGi Bundle-Name as the artifact ID

[ashvinctrl]

Description

Tomcat hand-writes the OSGi headers for every jar it ships and includes no pom, so syft names those jars from the filename. catalina.jar comes out as pkg:maven/org.apache.tomcat-catalina/catalina@10.1.54 when the published artifact is org.apache.tomcat:tomcat-catalina, and nothing is published under the former, so a stock Tomcat install matches no advisories at all.

The artifact ID is already in the manifest as Bundle-Name. That field is often a human readable title rather than an ID, so this only prefers it over the filename when Bundle-SymbolicName is composed from it. In the same directory tomcat-jdbc.jar ("Apache Tomcat JDBC Connection Pool") and ecj-4.27.jar ("Eclipse Compiler for Java(TM)") both fail that check and keep the names they get today.

# before
pkg:maven/org.apache.tomcat-catalina/catalina@10.1.54
# after
pkg:maven/org.apache.tomcat/tomcat-catalina@10.1.54

15 of the 35 jars in apache-tomcat-10.1.54/lib get corrected coordinates and all 15 resolve on Maven Central under org.apache.tomcat. Scanning the before and after SBOMs with grype v0.117.0 goes from 0 matches to 7 on 10.1.54 (3 critical, 3 high, 1 low, all on tomcat-catalina) and from 4 to 17 on both 9.0.111 and 11.0.13. Every new match is an exact-direct-match against a GHSA advisory for that artifact rather than CPE over-matching, and no existing match is lost. The group ID table already had the corrected names except tomcat-coyote-ffm, which is added here. I also ran a before/after over 39 jars pulled from Maven Central (spring, jetty, felix, eclipse platform, servicemix, cxf, camel, activemq, jackson, netty and others) and no purls changed.

Type of change

• Bug fix (non-breaking change which fixes an issue)

Checklist

• I have added unit tests that cover changed behavior
• I have tested my code in common scenarios and confirmed there are no regressions
• I have added comments to my code, particularly in hard-to-understand sections

Issue references

Fixes #4097

Also the cause of anchore/grype#3491, and the reason #4953 could not work on its own: the group ID mapping was already correct, but the artifact ID was still coming from the filename.

[ashvinctrl]

Only DCO has run on this PR so far. The rest of the checks are still waiting on a maintainer to approve workflow runs for a first-time contributor, so CI has not actually exercised the change yet. Could someone kick that off?

I ran it locally on the PR head in the meantime:

• go build ./... is clean.
• The new selectName cases in parse_java_manifest_test.go pass.
• go test ./syft/pkg/cataloger/java/... reports 15 failures, but those same 15 fail identically on upstream main on this machine (Windows fixture and docker-dependent tests), so nothing here is a regression from the change.

Happy to answer anything on the Bundle-Name heuristic or to add cases if you want the guard tightened.