[BUG] DiscoveryUpstreamServiceImpl.listAll() N+1 (3H+1 queries) on every discovery-upstream change

## Description
For each discovery handler `d` (H of them) it issues three separate mapper calls inside the lambda: `discoveryRelMapper.selectByDiscoveryHandlerId(d.getId())`, `selectorMapper.selectById(...)`/`proxySelectorMapper.selectById(...)`, and `discoveryUpstreamMapper.selectByDiscoveryHandlerId(d.getId())`. That is 3H+1 round-trips. This method is the cache builder called by `AbstractDataChangedListener.updateDiscoveryUpstreamDataCache` on every discovery-upstream change, then broadcast to every gateway.

## Location
```
shenyu-admin/.../service/impl/DiscoveryUpstreamServiceImpl.java:149-171
```

## Impact
At scale (many proxy-selector handlers) each upstream change costs O(H) DB queries + O(H) in-memory fan-out.

## Suggested fix
Fetch all `discovery_rel`, all `discovery_upstream`, and referenced selectors/proxy-selectors in three batched `IN (...)` queries, then stitch in memory.

## 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/.../service/impl/DiscoveryUpstreamServiceImpl.java:149-171 and trace the cache-building call from AbstractDataChangedListener.updateDiscoveryUpstreamDataCache. Review the discovery relation, upstream, selector, and proxy-selector mapper calls, then verify that batched lookups produce the same cache data with fewer database round-trips. The change is done when the N+1 pattern is removed without changing the broadcasted cache contents.

Written by the indexing model from the issue text.