load

The class as one of those loaders DEFINES it, or null when none does — including the ordinary mod runtime, where there are no plugins at all.

findResource is the design: public on URLClassLoader, searches that loader's own urls, does not delegate. It buys three things at once.

• It fits every shape here. Aiming at the plugin loaders' four-arg loadClass(name, resolve, checkGlobal, checkLibraries) would not: a jar-in-jar loader has no such method, and its plain loadClass delegates to the plugin loader, which answers for every OTHER plugin and makes Spigot log "not a depend or softdepend" against the wrong one. findClass is no way out either — inherited from java.net.URLClassLoader, so setAccessible throws InaccessibleObjectException without an --add-opens.
• It makes checkGlobal moot instead of something to pass false: past the gate the name IS in this loader's urls, so loadClass hits locally before any global search.
• ~0.5µs, so a miss — the common case — loads nothing.

The identity check enforces what the gate promised. A plugin loader is parent-first, so a name the game loader also has comes back as the game's copy — which the caller already tried and rejected.