fix: ClassPathScanner — Filter to NeonBee module JARs only

[ikalachy]

ClassPathScanner — Filter to NeonBee module JARs only

Overview

This change addresses a blocked thread issue in Kubernetes/Kyma environments where scanForAnnotation blocks a Vert.x worker thread for 87+ seconds reading all JARs on the classpath. The fix pre-filters JARs by checking their manifest for NeonBee-* attributes before doing the expensive filesystem walk.

Correctness

• Reading a small MANIFEST.MF is cheaper than opening a FileSystem and walking an entire JAR.
• Public API preserved. scanJarFilesWithPredicate(Vertx, Predicate) delegates with url -> true, so existing callers (including forJarFile) are unaffected.
• One subtle issue: isNeonBeeJar reads the manifest via manifestUrl.openStream(), and then later in the loop, the same manifest URL is used to create a FileSystem. This means the manifest is read twice for NeonBee JARs (once in the filter, once when
  FileSystems.newFileSystem opens it). Not a correctness bug, but a minor inefficiency. Given the goal is to skip 100+ non-NeonBee JARs, the double-read of the few NeonBee JARs is negligible.

[carlspring]

LGTM! :)