[Bug] Lite client info queries do not validate subscription ownership

### Runtime platform environment

Windows, local broker processor unit tests with mocked metadata and subscription registry.

### RocketMQ version

`develop` at `ff8f6f74c560e391261ccd716707c6d20422e253` (5.5.1).

### JDK Version

Amazon Corretto 8u482; Maven 3.9.11.

### Describe the Bug

`GET_LITE_CLIENT_INFO` validates that the requested consumer group is bound to the requested parent topic, then looks up the client's subscription by `clientId` alone. It does not compare the returned subscription's group and topic with the request.

Consequently, a query with a valid topic/group pair and a client belonging to another group can return `SUCCESS`. The response labels come from the request, while the subscription count, topics, and last-access information come from that other client. This produces misleading client diagnostics even when the client's subscription set is empty.

### Steps to Reproduce

1. Configure Lite groups `group1` and `other_group` bound to `parent_topic`.
2. Register `client1` under `other_group`.
3. Send `GET_LITE_CLIENT_INFO` for `(parent_topic, group1, client1)`.
4. The processor returns success instead of rejecting the mismatched client subscription.

The accompanying regression test serializes the request header and calls `processRequest`. On the unmodified processor it fails with `expected:<29> but was:<0>` (`INVALID_PARAMETER` versus `SUCCESS`). The same missing check also affects a subscription whose parent topic differs from the requested topic.

### What Did You Expect to See?

Validate both fields of an existing subscription against the requested group and parent topic before returning client details. Return `INVALID_PARAMETER` on mismatch, without a response body or the actual subscription's metadata in the error message.

### What Did You See Instead?

`SUCCESS`, with the client's information reported under the requested topic/group regardless of the subscription's actual ownership.

### Additional Context

`LiteSubscriptionRegistryImpl.getOrCreateLiteSubscription` already records the group and topic in each `LiteSubscription`, so no protocol or registry changes are required.

Matching subscriptions should still succeed, including an empty subscription set. An absent subscription should retain the existing success response with `liteTopicCount=-1`. No live-cluster or ACL behavior was tested; the reproduced issue is the inconsistent processor response.

Start at the GET_LITE_CLIENT_INFO processor's processRequest path and inspect LiteSubscriptionRegistryImpl to understand the recorded group and parent topic. Run the accompanying regression test first, then verify mismatched group or topic requests return INVALID_PARAMETER without a response body or leaked metadata. Matching subscriptions, empty subscription sets, and absent subscriptions should retain their stated behavior.

Written by the indexing model from the issue text.