[BUG] addToFail dedup key omits namespaceId and identity fields — drops distinct / newer failed registrations

- Severity: Medium
- Location:
`shenyu-register-center/shenyu-register-client/shenyu-register-client-api/src/main/java/org/apache/shenyu/register/client/api/FailbackRegistryRepository.java:126` (meta key), `:140` (uri key), `:154` (apiDoc key), `:169` (mcp key), `:175-184` (addToFail skip)
-
Description:
`addToFail` builds the failback key from a field subset that omits `namespaceId` (and per type, methodName/serviceName/parameterTypes/contextPath/ruleName/appName/version): meta key = `rpcType://host:port/path`; uri key = `host:port:rpcType`; apiDoc key = `contextPath:apiPath:httpMethod:rpcType`; mcp key derives from the embedded `MetaDataRegisterDTO` without namespaceId. When a Holder already exists for a key, `addToFail` returns immediately (`:177-179`): (a) a *different* DTO colliding on the coarse key is never enqueued, and (b) a *newer* version (updated rpcExt/status/instanceInfo/version) is discarded, so `accept()` later persists the *stale* original. The DTOs' own `equals/hashCode` include namespaceId and far more fields — the dedup key is inconsistent with DTO identity.
-
Impact:
Failed metadata/uri/apiDoc/mcp registrations for one namespace/variant are silently dropped from failback, or retried with stale content; never persisted until the client happens to re-register.
-
Suggested fix:
Derive the key from the same fields the DTO's `equals/hashCode` use (or use the DTO's `hashCode()`); on collision, *replace* the stored Holder with the newer payload instead of skipping.
-
Confidence: High
- Related existing: none. FUNC-E3 is the server-side URI batch namespace bug; this is the client-side failback dedup key. #4801 is the server-side `FallbackShenyuClientRegisterService` stale-retry (different class). FUNC-E1/E2 are exhaustion/race, not coarse-key dedup.

---
_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 in shenyu-register-center/shenyu-register-client/shenyu-register-client-api/src/main/java/org/apache/shenyu/register/client/api/FailbackRegistryRepository.java at the meta, URI, apiDoc, and mcp key construction and addToFail skip branches around lines 126-184. Compare those keys with the corresponding DTO equals/hashCode fields, then trace accept() to confirm how a stored Holder is persisted. Done means distinct registrations are retained and a collision keeps the newer payload for failback.

Written by the indexing model from the issue text.