fix(client): cap consumer connection group scan at a defensive limit

[yyqdbngt]

Summary

• Cap RocketMQClientProvider.findConsumerConnections at 200 consumer-group connection queries per scan (MAX_CONSUMER_GROUPS_SCANNED)
• Log a warning when the cap is hit so partial listings are visible in the server log
• Add a regression test with a 300-group cluster asserting exactly the cap is queried

Why

The consumer connection page scans every subscription group in the cluster and issues one sequential examineConsumerConnectionInfo admin RPC per group, with no cap. On a long-running cluster whose group table has grown to thousands of entries, a single page load issues thousands of sequential broker round-trips and can hold the request thread for minutes — far past the frontend's request timeout. The cap bounds the worst case at the cost of a logged partial listing (system groups still don't count against it).

Testing

• mvn -Dtest='RocketMQClientProviderTest,ProducerConnectionServiceTest,ClientServiceTest' test → RocketMQClientProviderTest 25/25 (incl. new cap regression), ProducerConnectionServiceTest 7/7, ClientServiceTest 5/5

[RockteMQ-AI]

Summary

This PR contains moderate changes (64 lines). I have performed an initial structural review.

Observations

• Changes appear well-scoped
• CLA status: unknown

Maintainers: please verify the implementation details match the intended behavior.

---

Automated review by github-manager-bot

[RockteMQ-AI]

Summary

Defensive fix that improves input validation and error handling. Code looks clean and follows existing patterns.

LGTM

---

Automated review by "github-manager-bot"

[RockteMQ-AI]

LGTM — defensive fix improving input validation and error handling.

---

Automated review by "github-manager-bot"