[Bug] Subscription Properties aren't enforced for Consumer

### Search before asking

- [x] I searched in the [issues](https://github.com/apache/pulsar-client-cpp/issues) and found nothing similar.

### Version

Using Pulsar v3.0.7 and pulsar-client-cpp 3.7.1

### Minimal reproduce step

Connect two shared consumers to the same topic under the same subscription name, but specify different subscription properties in the ConsumerConfiguration.

### What did you expect to see?

When the subscription is created, it was have persistent properties set matching one of the consumers' configurations. According to the doc comment on the subscription properties configuration here: https://github.com/apache/pulsar-client-cpp/blob/main/include/pulsar/ConsumerConfiguration.h#L518, if the properties specified don't match those on the broker, the consumer should fail to connect. The comment doesn't say what error code will be returned... and I don't see anything that really corresponds to this condition in the `pulsar::Result` enum.

### What did you see instead?

The consumer connects just fine with the wrong properties and will receive messages. There is no error returned from the `subscribe` method. The properties don't change, which is expected.

### Anything else?

Is this a bug, or is the comment incorrect? The comment on the [Java API] is similar, but I'm wondering if they're both wrong, since presumably this would be enforced on the broker? The lack of a `pulsar::Result` code for this condition makes me think this behavior was never implemented. The comment is somewhat incoherent in any case: it claims `consumers under the same subscription will fail to create a subscription if they use different properties`, but consumers under the same subscription won't be *creating* a subscription more than once either way: the first one to connect creates the subscription, and the others connect to that subscription. Furthermore, I wouldn't necessarily call the properties "immutable", since there's an admin API endpoint to change them.

I'm happy to file a bug under the main Pulsar project if this behavior *is* expected, but I suspect these comments are just incorrect. I just want to confirm what the expected behavior is going forward before I make a wrong design choice in my application. Thank you!

### Are you willing to submit a PR?

- [ ] I'm willing to submit a PR!

Start at include/pulsar/ConsumerConfiguration.h around line 518, then trace the subscribe path and pulsar::Result enum; compare the documented C++ behavior with the Java API and broker-side subscription-property handling. Done means the expected behavior is confirmed and the documentation or error handling is aligned, with a regression test if this path has repository coverage.

由索引模型根据 Issue 内容生成。