[Enhancement][Discussion] Cache serialized topic route data in NameServer getRouteInfoByTopic

### Before Creating the Enhancement Request

- [x] I have confirmed that this should be classified as an enhancement rather than a bug/feature.

### Summary

Discussion: cache the serialized route data in NameServer's `getRouteInfoByTopic` instead of deep-copying and JSON-encoding the full route on every request.

### Motivation

`ClientRequestProcessor#getRouteInfoByTopic` currently does two allocation-heavy steps per request:

1. `RouteInfoManager#pickupTopicRouteData` deep-copies the route under the read lock: a new `TopicRouteData`, a `LinkedList` of per-broker `BrokerData` clones, plus queue-data/filter-server containers.
2. `topicRouteData.encode(...)` serializes the copy to JSON.

Clients poll routes periodically (30s by default), so with a few thousand clients this pair dominates NameServer allocation, and none of it changes between route updates — the same topic's route is re-copied and re-encoded thousands of times per registration epoch.

### Rough direction (for discussion)

Cache the encoded `byte[]` per topic and invalidate on route mutation (register/unregister broker, topic config changes, broker liveness changes). Three parts make this non-trivial, which is why this is a discussion issue rather than a PR:

- `orderTopicConf` is looked up from KV config and merged into the response at query time, so either the KV lookup stays outside the cache key or KV changes must also invalidate.
- Requests are answered with two different JSON shapes (standard JSON for clients >= 4.9.4 or `acceptStandardJsonOnly`, the legacy fastjson shape otherwise), so the cache needs two variants per topic.
- With `supportActingMaster` enabled the route is post-processed per request, which would have to move inside the cached computation or gate the cache.

If maintainers see a simpler angle (e.g. caching only the deep copy and keeping per-request encoding, or a versioned copy-on-write route snapshot), happy to take that direction instead. I can follow up with an implementation and benchmark numbers once the approach is agreed.

Start with ClientRequestProcessor#getRouteInfoByTopic and trace RouteInfoManager#pickupTopicRouteData plus TopicRouteData.encode(...). Review route mutations, orderTopicConf lookup, JSON variants, and supportActingMaster handling before proposing a design. Done means maintainers agree on the cache boundary, invalidation rules, and validation or benchmark plan.

Written by the indexing model from the issue text.