[KYUUBI #7733][UTIL] Fall back to ReflectUtils's own loader when the context loader is null

[LuciferYang]

Why are the changes needed?

Closes #7733.

Stacked on #7724; its commit is the first of the two here, and the diff reduces to the second commit once #7724 merges.

ReflectUtils.isClassLoadable defaults its loader to the thread context classloader. On a thread whose context loader is null, DynClasses.builder().loader(null) resolves the name through Class.forName(name, true, null), which delegates to the bootstrap loader. The bootstrap loader sees only JDK classes, so the probe answers false for every application class, including Kyuubi's own, even when it is loadable through the loader that defined ReflectUtils.

This falls back to ReflectUtils's own classloader when the effective loader is null, matching Spark's getContextOrSparkClassLoader. The change is monotonic: a non-null loader behaves exactly as before, and a null loader can only turn a false into a true (an application class becomes loadable), never the reverse. Repository threads carry a non-null context loader under normal startup, so this is defensive hardening for embedded hosts (a JNI invocation that never sets a context loader, a container framework that clears it) and third-party callers of this public helper.

How was this patch tested?

Added a ReflectUtilsSuite case that sets the thread context loader to null (restored in finally) and asserts an application class is loadable while a non-existent one is not. It fails without the fallback, since the bootstrap loader cannot see the class.

build/mvn test -pl kyuubi-util-scala -am
build/mvn scalastyle:check spotless:check -pl kyuubi-util-scala -am

Module green on Zulu 17.0.18 (23/23), scalastyle 0 errors, spotless clean.

Was this patch assisted by generative AI tooling?

Assisted-by: Claude Opus 4.8