[Studio][Bug] Consumer group detail and offset-reset preview fail for groups that never connected or use broadcast mode

[Studio][Bug] Consumer group detail and offset-reset preview fail for groups that never connected or use broadcast mode

## Problem

On the Apache vendor path, `RocketMQAdminClientImpl` treats two ordinary group states as hard failures:

- **Group created but whose clients never connected** (the retry topic `%RETRY%` has no route yet): the group detail endpoint returns **502 "Failed to get consumer group: CODE: 17 DESC: No topic route info in name server for the topic: %RETRY% ..."**
- **The same group state, or a broadcast-mode group, in the offset-reset preview**: returns **500 "Failed to preview reset offset: CODE: 17/213 DESC: ..."**

## Evidence

- rocketmq-tools 5.5.0 bytecode: `DefaultMQAdminExtImpl.examineConsumerConnectionInfo` and `examineConsumeStats` both locate the group through `MixAll.getRetryTopic(group)` via `examineTopicRouteInfo`, which delegates to `MQClientAPIImpl.getTopicRouteInfoFromNameServer`; that call throws `MQClientException(TOPIC_NOT_EXIST=17, "No topic route info in name server for the topic: ...")` when the retry topic has no route. `examineConsumeStats` throws `MQClientException(BROADCAST_CONSUMPTION=213, "... the consumer is under the broadcast mode")` for a broadcast group's empty offset table.
- `RocketMQAdminClientImpl.isConsumerNotOnline` (RocketMQAdminClientImpl.java:234-241 at 6c24d2ed) only matches `MQBrokerException(CONSUMER_NOT_ONLINE)` or messages containing `"not online"` / `"CODE: 206"` - neither the CODE 17 nor the CODE 213 variant matches, so `getConsumerGroup` throws 502 and `doPreviewResetOffset` throws 500.
- Three new regression tests in `RocketMQAdminClientImplTest` are red on current code with exactly the outputs above.

## Impact

Creating a consumer group in Studio and immediately opening its detail fails with an opaque 502 (the group cannot have a retry-topic route before any client connects). The reset-offset preview fails with 500 for the same group and for broadcast groups, blocking the preview-first reset flow.

## Expected behavior

Both states should be graded like the existing not-online branch: an empty group detail (with the proxy fallback still consulted) and an empty "not online" preview instead of 502/500.

## Related work

- #1250 (closed 2026-08-07, no implementing PR found) proposed surfacing unavailable runtime diagnostics as errors - the opposite direction for the failure/empty boundary. This issue is narrower: the two graded states are "RPC succeeded but there is no business data" (TOPIC_NOT_EXIST for the group's %RETRY% route, BROADCAST_CONSUMPTION for an empty offset table), which the same methods already grade as not-online in other message variants; genuine broker/admin failures still throw after this change.
- #4006 / merged fix graded offline group connections to empty results in `RocketMQClientProvider`; #4258/#4259 grade the drifted copy in `RocketMQMetadataProvider`. The `ensureRetryTopicExists` javadoc in `RocketMQMetadataProvider` (added with the POP support) documents the same CODE 17 failure mode; `RocketMQAdminClientImpl` has no equivalent mitigation or grading.

## PR

Fix: #4261.

Start in RocketMQAdminClientImpl.java, especially isConsumerNotOnline and the getConsumerGroup and doPreviewResetOffset paths. Run the three new regression tests in RocketMQAdminClientImplTest and compare their current failures with the expected empty detail and not-online preview behavior. Genuine broker or admin failures should still be reported.

Written by the indexing model from the issue text.