[branch-4.1][fix](ngram-bf) Give up the NGRAM index when a LIKE pattern can carry an escape (#68021)

[selectdb-robot]

What problem does this PR solve?

Related PR: #68021

Backport #68021 to branch-4.1 to prevent NGRAM Bloom Filter pruning from dropping matching rows when a LIKE pattern contains a backslash or uses a custom ESCAPE. Escape-free patterns remain eligible for the index.

Cherry-picked from 2fe54ad3516e0638444f91f4581d1127bb48a411.

One conflict was resolved in TabletReader::_init_conditions_param: retain branch-4.1's function_filters loop and is_like_predicate(pred) check, and add pred->can_do_bloom_filter(true) to the existing index initialization guard. The other BE changes and the regression suite are unchanged from the original patch.

Validation

• git diff --check passed; no unresolved conflicts.
• Verified the patches for olap_scan_operator.cpp and like_column_predicate.h match the original commit.
• Verified test_ngram_bloomfilter_index_like_escape.groovy is identical to the original commit.
• Confirmed branch-4.1 already has LikeState::has_custom_escape.
• Compilation and runtime regression tests were not run in this session; CI validation remains pending.

Release note

Fix incorrect LIKE query results with NGRAM Bloom Filter indexes when the pattern contains an escape.

Check List (For Author)

• Test
  • Regression test included from [fix](ngram-bf) Give up the NGRAM index when a LIKE pattern can carry an escape #68021 (not executed in this session)
  • Unit Test
  • Manual test
• Behavior changed:
  • Yes. Skip NGRAM Bloom Filter pruning for LIKE patterns that can carry an escape.
• Does this need documentation?
  • No.

Check List (For Reviewer who merge this PR)

• Confirm the release note
• Confirm test cases
• Confirm document
• Add branch pick label

[hello-stephen]

Thank you for your contribution to Apache Doris.
Don't know what should be done next? See How to process your PR.

Please clearly describe your PR:

1. What problem was fixed (it's best to include specific error reporting information). How it was fixed.
2. Which behaviors were modified. What was the previous behavior, what is it now, why was it modified, and what possible impacts might there be.
3. What features were added. Why was this function added?
4. Which code was refactored and why was this part of the code refactored?
5. Which functions were optimized and what is the difference before and after the optimization?

[csun5285]

run buildall

[hello-stephen]

BE Regression && UT Coverage Report

Increment line coverage 100.00% (12/12) 🎉

Increment coverage report
Complete coverage report

Category	Coverage
Function Coverage	74.42% (31437/42241)
Line Coverage	58.71% (350638/597226)
Region Coverage	55.45% (292660/527830)
Branch Coverage	56.31% (132079/234550)