[BUG] No config-change coalescing: each imported selector/rule triggers a full-namespace cache rebuild + broadcast

## Description
There is no coalescing anywhere. `SelectorServiceImpl.importData` calls `create(selectorDTO)` per imported row -> one `DataChangedEvent` per row. `AbstractDataChangedListener.onSelectorChanged` rebuilds the entire namespace cache per event (`updateSelectorCache` -> `listAll()`) with no debounce window. So K rapid selector changes = K full-namespace scans + K MD5 hashes of the entire selector JSON + K broadcasts to every gateway.

## Location
```
shenyu-admin/.../service/impl/SelectorServiceImpl.java:478-525,529-588,228-239,242-277
RuleServiceImpl mirrors; AbstractDataChangedListener.java:233-240,353-395
```

## Impact
A 1000-row selector import fires 1000 sequential full-namespace cache rebuilds and 1000 broadcasts to every gateway.

## Suggested fix
Batch events at the service layer (publish one event with the full changed list, or coalesce in a short time window); have `AbstractDataChangedListener` skip the rebuild when an identical-md5 event is already pending.

## 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)._

Read SelectorServiceImpl.java at lines 478-525, 529-588, 228-239, and 242-277, then compare the corresponding RuleServiceImpl flow with AbstractDataChangedListener.java lines 233-240 and 353-395. Trace an import through event publication, cache rebuilding, hashing, and gateway broadcast. Done means rapid imported changes are coalesced so they do not cause one full-namespace rebuild and broadcast per row.

Written by the indexing model from the issue text.