[BUG] Node sync auth and metadata deletes unsubscribe the wrong cache key

### Current Behavior

Node-based sync consumers unsubscribe auth and metadata entries using the wrong key segment.

The admin node listener writes app-auth and metadata entries under keys shaped like:

```text
..
..
```

`AbstractNodeDataChangedListener` builds those prefixes and appends `AppAuthData::getAppKey` or `MetaData::getId`.

On delete, `AbstractNodeDataSyncService` splits the remove key but uses `ruleKeys[1]` as the deleted identifier:

```java
appAuthData.setAppKey(ruleKeys[1]);
metaData.setId(ruleKeys[1]);
```

For a key like `namespace.auth.actualAppKey`, `ruleKeys[1]` is only `auth`, not the deleted app key. The same applies to metadata, where `ruleKeys[1]` is `meta`.

### Expected Behavior

Auth and metadata delete events should unsubscribe the actual deleted identifier from the final key segment.

### Impact

Apollo/Nacos/Polaris-style node sync clients can keep stale app auth or metadata cache entries after those records are deleted in admin.

### Code Location

- `shenyu-admin-listener/shenyu-admin-listener-api/src/main/java/org/apache/shenyu/admin/listener/AbstractNodeDataChangedListener.java`
- app auth and metadata keys are written with the actual id/appKey as the final segment.
- `shenyu-sync-data-center/shenyu-sync-data-api/src/main/java/org/apache/shenyu/sync/data/core/AbstractNodeDataSyncService.java`
- `unCacheAuthData()` and `unCacheMetaData()` read `ruleKeys[1]` instead of the final identifier segment.

Start with AbstractNodeDataSyncService.java, specifically unCacheAuthData() and unCacheMetaData(), then compare their key parsing with the key construction in AbstractNodeDataChangedListener.java. Done means delete events use the final app key or metadata ID segment, so node sync clients unsubscribe the deleted entries rather than retaining stale cache data.

Written by the indexing model from the issue text.