[BUG] HashLoadBalancer rebuilds consistent-hash ring + allocates MD5 MessageDigest per virtual node per request

## Description
`doSelect` allocates a fresh `ConcurrentSkipListMap` and, for every upstream x 5 virtual nodes, calls `hash("SHENYU-" + upstream.getUrl() + "-HASH-" + i)` which does `MessageDigest.getInstance("MD5")` (JCA lookup + new instance), `key.getBytes(UTF_8)`, and `md5.digest()` (new `byte[]`). The ring is never cached; it is fully rebuilt on every selection even though the upstream set only changes on health-check/admin events.

## Location
```
shenyu-loadbalancer/.../spi/HashLoadBalancer.java:44-56 (doSelect), 58-77 (hash)
```

## Impact
Per hash-LB request: 1 SkipListMap + 5*N MD5 instances + 5*N String concatenations + 5*N `byte[]` digests. For N=10 upstreams that's 50 MD5 hashes/request. Very high CPU + allocation on the sticky/consistent-hash path; scales linearly with RPS and upstream count.

## Suggested fix
Build and cache the ring (e.g. `ConcurrentHashMap>` keyed by selectorId, invalidated when `UpstreamCacheManager.submit`/health-check mutates the list). Use a `ThreadLocal` or a faster non-crypto hash (murmur3/xxHash). Precompute virtual-node keys when the upstream list changes.

## 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 with shenyu-loadbalancer/.../spi/HashLoadBalancer.java:44-77, reading doSelect and hash to measure the current ring and digest allocations. Trace UpstreamCacheManager.submit and health-check list mutations to determine invalidation points. Done means the ring and hash-related work are not rebuilt for every selection, while selection behavior remains consistent when upstreams change.

Written by the indexing model from the issue text.