[BUG] HttpLongPollingDataChangedListener: single-thread scheduler + global synchronized(this) full-cache refresh

## Description
One scheduler thread runs the periodic `refreshLocalCache`, every `DataChangeTask` notification to all long-polling clients, and every `LongPollingClient` timeout future. `checkCacheDelayAndUpdate` takes `synchronized(this)` — a process-wide lock across all groups/namespaces — and inside it calls `super.refreshLocalCache()` which loops all namespaces and rebuilds all eight caches under the lock. Every long-polling compare that detects a stale md5 turns into a full-DB scan holding the global lock, blocking every other concurrent long-polling compare.

## Location
```
shenyu-admin/.../listener/http/HttpLongPollingDataChangedListener.java:111 (new ScheduledThreadPoolExecutor(1, ...)), 261 (synchronized(this) in checkCacheDelayAndUpdate)
```

## Impact
With many gateways holding long polls, one stale md5 triggers a global full-DB rebuild that blocks every other long-poll compare. O(total_config) work per stale-detect under a global lock.

## Suggested fix
Increase scheduler parallelism; narrow the lock to per-namespace; make `refreshLocalCache` namespace-scoped.

## Related existing issue(s)
None

_Identified during the 2026-08-02 audit; full list in [`docs/issue-candidates-2026-08-02.md`](docs/issue-candidates-2026-08-02.md)._

Start in shenyu-admin/.../listener/http/HttpLongPollingDataChangedListener.java at the scheduler setup around line 111 and checkCacheDelayAndUpdate around line 261. Trace refreshLocalCache and the long-poll notification and timeout paths, then verify that stale-md5 handling no longer forces unrelated namespaces through one global lock while preserving cache refresh and client notifications.

Written by the indexing model from the issue text.