fix(core): resolve dependencies and change classes across classloader…

[dieppa]

… boundaries

Fixes #951. Under Spring Boot DevTools restart, application classes are reloaded through a separate RestartClassLoader while Flamingock's own classes stay on the base loader. Two Class<?> objects with the same fully-qualified name but different defining classloaders are never equal, so Flamingock failed to resolve dependencies and change/param types it had just registered, surfacing as a misleading "Dependency not found" error.

• CodeLoadedChangeBuilder: resolve change classes via a classloader fallback chain (thread context classloader, then this class's own loader, then the system loader) instead of relying solely on the implicit default of Class.forName, so it picks up the same "live" app classes the framework is actually using.
• SimpleContext: fall back to matching dependencies by fully-qualified class name when exact-type and assignability lookups miss, covering manually registered dependencies split across classloaders. Logs a warning when this fallback is used so a genuine duplicate-class issue on the classpath doesn't get silently masked.
• Add ClassloaderMismatchReproTest, simulating the dual-classloader scenario to guard against regressions.