Fall back to the library class loader for classpath resources - #1265

No blocking findings.

Risk: Medium-low. The code change is tiny, but ClasspathResourceLoader#getResource sits under schema loading and $ref/meta-schema resolution. GitNexus shows direct callers in
SchemaLoader.getSchemaResource, SchemaLoader.getClasspathResource, and Schema.getInputResource, with the affected flow centered on schema loading.

Coverage looks good for the intended behavior:

• fallback when TCCL cannot see bundled resources: json-schema-validator/src/test/java/com/networknt/schema/resource/ClasspathResourceLoaderTcclTest.java:66
• TCCL still wins when it can resolve the resource: json-schema-validator/src/test/java/com/networknt/schema/resource/ClasspathResourceLoaderTcclTest.java:74
• explicit custom classloader source is not overridden: json-schema-validator/src/test/java/com/networknt/schema/resource/ClasspathResourceLoaderTcclTest.java:95

Areas to improve, non-blocking:

• There is no committed real OSGi/Felix integration test. The stub classloader regression test is reasonable and cheap, but the actual bundle classloader behavior remains manually
  verified.

• The fallback uses ResourceLoader.class.getClassLoader() at json-schema-validator/src/main/java/com/networknt/schema/resource/ClasspathResourceLoader.java:85. That should be equivalent
  in this package, but ClasspathResourceLoader.class.getClassLoader() would make the intent slightly more local and explicit.

It appears that PR #1265 contains the exact same code changes as PR #1266 (both modifying ClasspathResourceLoader.java and adding ClasspathResourceLoaderTcclTest.java with 123 insertions). They likely represent duplicate PRs opened by the author (perhaps accidentally or against different branches).

Since the codebase changes are identical, my previous review applies in its entirety to this PR as well.

To summarize:

• The fix is correct: It safely falls back to the library's own class loader when the Thread Context Class Loader (TCCL) fails to find bundled resources (which is the root cause of the OSGi issue).
• It preserves backward compatibility: Custom class loader suppliers are respected and do not trigger the fallback unexpectedly.
• The tests are solid: They cover both the blind TCCL case and cases where TCCL and the library class loader compete.

Status: Approved / LGTM (Looks Good To Me).

You can safely merge whichever of the two PRs (#1265 or #1266) targets the branch you intend to update, and close the other as a duplicate!