[NUAAwqy]

What does this PR do?

The paged topic list filtered system topics with notLikeRight patterns containing unescaped % and _, so SQL treated them as wildcards: ordinary topics such as orders_RETRY_archive disappeared from paged results while the unpaged list (which uses literal prefix checks in SystemTopicFilter) still showed them. The literal prefixes are now backslash-escaped, matching the existing escapeLike convention, with a wrapper-level regression test.

Fixes #7071

[NUAAwqy]

This PR's CI failure is a baseline failure on the rocketmq-studio branch, not caused by these changes.

• The failing job is Frontend Build (Node 20), with both failures in web/src/pages/instance/__tests__/ConsumerPage.test.tsx:
  • keeps the latest client stack when an older request resolves last (expects LatestClientThread)
  • highlights inconsistent subscriptions and refreshes the check result (expects 全部 2 个订阅配置一致)
• This PR only touches server/.../RocketMQMetadataProvider.java and its unit test — no frontend files are modified.
• Evidence the base branch itself is red: the direct push to rocketmq-studio at the current HEAD 127c47b0 (this PR's exact base) fails with the identical ConsumerPage.test.tsx:1456 error: https://github.com/apache/rocketmq-dashboard/actions/runs/39257998487 (run #8715).
• The same failures hit other unrelated PRs on the same base (e.g. docs: document instance batch deletion and cloud import APIs #7233 fails on LatestClientThread; fix(consumer): handle large queue health inventories #7245/fix(acl): honor keyword filtering for user directory #7247/fix(consumer): order group progress by topic and queue #7251 fail on the 全部 2 个订阅配置一致 assertion).

Keeping the PR as-is; no code change here could make this green until the ConsumerPage test/behavior on the base branch is fixed.

(Full log of this PR's failed run: https://github.com/apache/rocketmq-dashboard/actions/runs/39278086710)

[NUAAwqy]

The Frontend Build (Node 20) failure here also reproduces on the base branch tip this PR is built on (127c47b0, see its Actions run), so it appears to be a pre-existing baseline issue unrelated to this change. Could a maintainer take a look or re-run the job once the baseline is fixed? Thanks!