fix(studio): escape SQL LIKE wildcards in data source and metadata search

[jokerzsd]

Summary

Escape SQL LIKE wildcards in two remaining search paths that were not covered by the earlier per-surface fixes (#4223, #4229, #4192, #4193, #4194, #4232).

Problem

• MybatisPlusSettingsRepository.findDataSources passed the raw search string into like("json", ...).
• RocketMQMetadataProvider passed the raw search string into like(RmqTopic::getName, ...) / like(RmqGroup::getName, ...).

Topic/group names and data source content can contain % and _, so a search treated those as LIKE wildcards and silently matched unrelated rows.

Fix

Introduce a shared SqlLikeUtils.escape helper (extracted from the escaping already used by QueryHistoryService) and apply it to the remaining unescaped predicates.

Test plan

Added SqlLikeUtilsTest. mvn test -Dtest=SqlLikeUtilsTest — 2 tests, 0 failures.

[RockteMQ-AI]

LGTM. Good catch on the remaining unescaped like() predicates. Extracting SqlLikeUtils.escape into a shared helper is the right call — it centralizes the escaping logic and prevents future regressions. The test coverage for edge cases (backslash, percent, underscore, empty/null) is solid.

---

Automated review by github-manager-bot

[lizhimins]

Closing, but please read this one as a request to resubmit rather than a rejection of the approach.

Putting the helper in common/util/SqlLikeUtils is exactly the shape we want, and this is the only patch in the LIKE-escape set that covers all four call sites in RocketMQMetadataProvider plus MybatisPlusSettingsRepository without touching the hard-coded notLikeRight. The blocking problem is dialect dependence: the escaping relies on MySQL's implicit backslash escape character, and without an explicit ESCAPE clause the same helper is wrong elsewhere — five tests in this suite run against H2, which has no default LIKE escape character, so the escaped pattern silently means something different there.

Add the explicit ESCAPE clause (and keep the tests asserting the bound parameter) and we will take it as the anchor for the whole cluster: #4192 #4193 #4194 #4224 #4230 #4233 #4290 are all closed or returned, so this is the one that should land.