[BUG] TarsMetaDataHandler dedup comparison is semantically wrong (host vs appName)

- severity: Medium
- files: `shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-rpc/shenyu-plugin-tars/src/main/java/org/apache/shenyu/plugin/tars/handler/TarsMetaDataHandler.java:44-49`
- description: `handle` decides whether to (re)initialize by `prxList.stream().anyMatch(prx -> prx.getHost().equals(metaData.getAppName()))`. But `TarsInvokePrx.host` is set to `upstream.getUpstreamUrl()` (e.g. `1.2.3.4:1080`), while the compared value is `metaData.getAppName()` (e.g. `HelloApp`). These never match, so `exist` is always false and `initPrx` is invoked on every metadata handle event.
- impact: Every tars metadata sync triggers a redundant `initPrx` → `refreshTarsInvokePrxList`, amplifying TARS-02's race window.
- suggested_fix: Compare against a field that actually holds the app name, or store the app name on `TarsInvokePrx`.
- confidence: Medium
- related_existing: none

---
_Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/06-medium-tiers.md`](docs/scan2-2026-08-02/06-medium-tiers.md)._

Start at shenyu-plugin/shenyu-plugin-proxy/shenyu-plugin-rpc/shenyu-plugin-tars/src/main/java/org/apache/shenyu/plugin/tars/handler/TarsMetaDataHandler.java:44-49 and trace handle through initPrx and refreshTarsInvokePrxList. Inspect TarsInvokePrx to identify the field that represents the app identity; done means repeated metadata handling recognizes an existing proxy instead of redundantly reinitializing it.

Written by the indexing model from the issue text.