fix(query): handle empty LIKE ESCAPE in planner

[sundy-li]

I hereby agree to the terms of the CLA available at: https://docs.databend.com/dev/policies/cla/

Summary

• Fixes LIKE ... ESCAPE '' panics in planner type checking #19562
• Stop the planner LIKE fast path from unwrapping an empty ESCAPE string.
• Preserve existing operator/builtin fallback behavior by routing empty or non-single-character ESCAPE literals through the builtin like / like_any path instead of planner rewrites.
• Add planner and sqllogictest regressions for empty-escape bindings and backslash-containing fallback cases.

Tests

• Unit Test
• Logic Test
• Benchmark Test
• No Test - Explain why

Validation:

• cargo test -p databend-common-sql --test it planner -- --nocapture
• cargo test -p databend-common-sql --test it test_like_escape_preserves_existing_binding_semantics -- --nocapture
• cargo clippy -p databend-common-sql --test it -- -D warnings
• cargo fmt --all --check

Logic test added for CI coverage:

• tests/sqllogictests/suites/query/issues/issue_19562.test

Type of change

• Bug Fix (non-breaking change which fixes an issue)
• New Feature (non-breaking change which adds functionality)
• Breaking Change (fix or feature that could cause existing functionality not to work as expected)
• Documentation Update
• Refactoring
• Performance Improvement
• Other (please describe):

---

This change is 

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 63f2779b9c

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[sundy-li]

Blocking issue in resolve_like(): this patch stops the panic for ESCAPE , but it also lets empty-escape patterns fall into the const/prefix fast paths even when those rewrites are not semantics-preserving.\n\nExample: SELECT ax LIKE a\\x ESCAPE . After this patch new_like_str is borrowed as a\\x, check_const() returns true, and the planner rewrites to equality against a\\x. The runtime LIKE matcher still treats backslash as escaping the next character, so that pattern behaves like ax and should return true, not false. The same issue applies to prefix rewrites like a\\x%.\n\nSo this changes the failure mode from a planner panic to silent wrong-answer plans for some empty-escape inputs. I think the safe options here are either to reject ESCAPE with a normal SQL error, or to bypass the const/prefix rewrites when the escape string is present but empty.