[Bug] Repeated subscription changed logs for unchanged gRPC subscriptions

### Before Creating the Bug Report

- [x] I have confirmed this issue has not been reported before.
- [x] I have searched the existing issues.

### Runtime platform environment

RocketMQ proxy with gRPC consumers and proxy heartbeat sync enabled.

### RocketMQ version

develop branch

### Describe the Bug

For gRPC consumers, `ClientActivity.registerConsumer()` rebuilds the subscription data set from the client `Settings` on each registration/heartbeat path. `FilterAPI.build()` creates a new `SubscriptionData`, whose default `subVersion` is initialized with `System.currentTimeMillis()`.

When the subscription topic and filter expression are unchanged, the newly built `SubscriptionData` still has a newer `subVersion`. `ConsumerGroupInfo.updateSubscription()` currently logs `subscription changed` whenever the incoming `subVersion` is greater than the stored one, so the broker/proxy can repeatedly log subscription changes even though the subscription content is identical.

This is especially visible on the proxy internal heartbeat sync path, where the log thread can be `HeartbeatSyncer`.

### Steps to Reproduce

1. Start RocketMQ proxy in cluster mode.
2. Register a gRPC consumer with a stable subscription.
3. Let the client continue sending heartbeat/settings updates or let proxy heartbeat sync propagate the registration data.
4. Observe repeated `subscription changed` logs with identical topic/filter content but different `subVersion` values.

### What Did You Expect to See?

The broker/proxy should only log `subscription changed` when the actual subscription content changes.

### What Did You See Instead?

The log is printed repeatedly because only `subVersion` changes.

### Additional Context

The repeated log is mostly noise and internal sync overhead, but it can make operational logs misleading and noisy for stable gRPC consumers.

Start by reading ClientActivity.registerConsumer(), FilterAPI.build(), and ConsumerGroupInfo.updateSubscription() to trace how subscription data and subVersion move through registration and heartbeat sync. Reproduce the proxy cluster scenario with a stable gRPC subscription, then verify that unchanged topic and filter content no longer produces repeated subscription-changed logs while real content changes still do.

Written by the indexing model from the issue text.