[BUG] — Dubbo plugin performs blocking registry connect / `ReferenceConfig.get()` on the event loop (cache-miss path)

- severity: Medium-High
- files: `shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-rpc/shenyu-plugin-dubbo/shenyu-plugin-apache-dubbo/src/main/java/org/apache/shenyu/plugin/apache/dubbo/cache/ApacheDubboConfigCache.java:253,282` (`reference.get()`); lazy-init fallback `ApacheDubboProxyService.java:135-140` (`initRefN` → `build` → `reference.get()`)
- description: On first request per path or after `invalidate`/cache expiry, `getReferenceConfig` calls `ReferenceConfig.get()` on the calling (event-loop) thread. `ReferenceConfig.get()` synchronously connects to the registry (Zookeeper/Nacos), resolves providers and builds the `GenericService` proxy — known blocking, potentially multi-hundred-ms.
- impact: Cold-start / metadata-refresh latency spikes on the Dubbo route; event-loop stalls when Dubbo references are lazily (re)built during traffic or registry flap.
- suggested_fix: Pre-warm references off the event loop (the metadata-sync path already has `initRef`); ensure lazy init in `genericInvoker` is removed or moved to `Mono.fromCallable(...).subscribeOn(boundedElastic())`.
- confidence: High

---
_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 ApacheDubboConfigCache.java at lines 253 and 282, then trace the lazy-init path in ApacheDubboProxyService.java:135-140 from initRefN through build and reference.get(). Compare it with the metadata-sync initRef path. Done means cold-cache and refresh initialization no longer performs the blocking registry connection on the event-loop thread.

Written by the indexing model from the issue text.