fix(tools): keep the broadcast track type in messageTrackDetailConcurrent

[zjncs]

Motivation

The serial messageTrackDetail maps the broadcast case to a proper track type:

} catch (MQClientException e) {
    if (ResponseCode.CONSUMER_NOT_ONLINE == e.getResponseCode()) {
        mt.setTrackType(TrackType.NOT_ONLINE);
        ...
    }
    if (ResponseCode.BROADCAST_CONSUMPTION == e.getResponseCode()) {
        mt.setTrackType(TrackType.CONSUME_BROADCASTING);
    }
    ...

but the concurrent variant (messageTrackDetailConcurrent, exposed via MQAdminExt.messageTrackDetailConcurrent) only handles CONSUMER_NOT_ONLINE in its catch blocks. For a broadcast consumer group, consumed() → examineConsumeStats throws MQClientException(ResponseCode.BROADCAST_CONSUMPTION, ...), so the concurrent API reports the group as TrackType.UNKNOWN with a raw error string, while the serial API correctly reports CONSUME_BROADCASTING — contradicting the sibling implementation and misleading dashboards that use the concurrent API.

Modifications

Add the same BROADCAST_CONSUMPTION → CONSUME_BROADCASTING mapping to both catches of the concurrent track task.

Verification

Fail-before (new test testMessageTrackDetailConcurrentWithBroadcastGroup, run against the unpatched code — a passive consumer group whose connection reports MessageModel.BROADCASTING, so examineConsumeStats throws BROADCAST_CONSUMPTION through the natural path):

Tests run: 1, Failures: 1 -- DefaultMQAdminExtImplTest
expected:<CONSUME_BROADCASTING> but was:<UNKNOWN>

Pass-after:

Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 -- DefaultMQAdminExtImplTest#testMessageTrackDetailConcurrentWithBroadcastGroup

Note: the pre-existing testMessageTrackDetailConcurrent (and testConsumeMessageDirectly) fail in my local container on JDK 21 with Mockito cannot mock this class: java.net.InetAddress — verified to fail identically on a clean develop checkout (before my changes), so this is an environment limitation, not a regression of this PR.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[RockteMQ-AI]

LGTM. Changes look good.

---

Automated review by github-manager-bot