[BUG] SpringBeanUtils.registerBean mutates the shared BeanFactory.beanClassLoader globally

- Severity: Medium
- Location:
`shenyu-plugin/shenyu-plugin-api/src/main/java/org/apache/shenyu/plugin/api/utils/SpringBeanUtils.java:85`
-
Description:
`beanFactory.setBeanClassLoader(classLoader); beanFactory.registerBeanDefinition(beanName, beanDefinition);`. `setBeanClassLoader` sets a single field on the shared `DefaultListableBeanFactory`, affecting type resolution for **all** beans, not just the one being registered. Every plugin registration overwrites the global classloader with that plugin's classloader.
-
Impact:
Plugin A registers (factory CL ← A). Plugin B registers (factory CL ← B). Any deferred type resolution for A's beans (lazy autowire, AOP proxy, bean created on first use) now uses B's classloader, which cannot see A's classes → order-dependent `ClassNotFoundException`/`BeanCreationException`.
-
Suggested fix:
Do not call `setBeanClassLoader` on the shared factory. Pass the classloader through the `BeanDefinition` (e.g. a custom `RootBeanDefinition` with a `Supplier` that does `Class.forName(name, false, pluginClassLoader)`).
-
Confidence: Medium
- Related existing: SEC-1 (RCE via defineClass) is the trust issue; this is a separate classloader-correctness bug.

---
_Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/06-medium-tiers.md`](docs/scan2-2026-08-02/06-medium-tiers.md)._

Start in shenyu-plugin/shenyu-plugin-api/src/main/java/org/apache/shenyu/plugin/api/utils/SpringBeanUtils.java at line 85 and trace plugin bean registration through the shared BeanFactory. Verify the deferred-resolution scenario described for beans from two plugins with different classloaders. Done means registration no longer mutates the shared factory's classloader and each plugin's deferred type resolution retains its own classloader.

Written by the indexing model from the issue text.