[Bug] Fix stale wildcardGroupMap entries caused by incorrect parsing during LiteTopic wildcard unregistration #10253

Before Creating the Bug Report

• I found a bug, not just asking a question, which should be created in GitHub Discussions.

• I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.

• I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.

Runtime platform environment

macos

RocketMQ version

5.5.0

JDK Version

jdk17

Describe the Bug

LiteTopic 的 wildcard group 在删除注册时，会使用 StringUtils.split(lmqName) 解析 topic@group 形式的占位键。由于该方法默认按空白字符分割，而不是按 @ 分割，导致解析结果长度不为 2，删除逻辑提前 return，wildcardGroupMap 中的 wildcard group 元数据永远无法被清理。长期运行后会残留失效 group，带来额外的 dispatch 扫描开销和潜在的内存增长问题。

During LiteTopic wildcard group unregistration, the code uses StringUtils.split(lmqName) to parse the placeholder key in the form of topic@group. Since this method splits on whitespace by default instead of @, the parsed result does not contain two parts, so the cleanup logic returns early and the wildcard group metadata remains in wildcardGroupMap. Over time, this can leave stale groups behind, causing unnecessary dispatch scans and potential memory growth.

Steps to Reproduce

null

What Did You Expect to See?

split by "@"

What Did You See Instead?

split by ""

Additional Context

No response