[fix](regression) stabilize MTMV SQL cache refresh checks

[shuke987]

What problem does this PR solve?

Issue Number: N/A

Related PR: #57177

Problem Summary:

mtmv_with_sql_cache intermittently required mtmv_sql1 to miss SQL cache after refreshing mv_name1. However, the case rebuilt that cache after INSERT OVERWRITE while the MTMV was stale. The cached physical plan could therefore scan only the two base tables. Refreshing the MTMV did not change either recorded base-table version, so retaining that cache entry was valid.

This change removes only that invalid cache-residency assumption while preserving the original test coverage:

• cache entries whose real base-table or MTMV dependencies change still must miss;
• with SQL cache disabled, the refreshed MTMV must be chosen for mtmv_sql1 rewrite;
• cached and uncached executions must return identical results.

The failure was observed in P0 build 992833, occurrence 2000001579, with the same original line 768 and base-table PhysicalSqlCache plan seen in earlier muted failures.

Release note

None

Check List (For Author)

• Test

  • Regression test
    • Runtime rerun is pending; this PR is intentionally opened as draft.
  • Unit Test
  • Manual test (add detailed scripts or steps below)
    • git diff --check
    • Verified mv_rewrite_success bypasses SQL cache here and checks .<mv_name> chose through the existing memo-plan helper.
    • Verified the surrounding base-table, direct-MTMV, and nested-MTMV cache invalidation assertions remain unchanged.
  • No need to test or manual test. Explain why:
    • This is a refactor/code format and no logic has been changed.
    • Previous test can cover this change.
    • No code files have been changed.
    • Other reason

• Behavior changed:

  • No.
  • Yes.

• Does this need documentation?

  • No.
  • Yes.

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?

[shuke987]

run buildall

[shuke987]

/review

[github-actions]

Review complete for head 4aa5619f5e61b242d42304f6f4072e10075a9378. I did not find a blocking issue or a substantiated inline finding.

Checkpoint conclusions:

• Goal and coverage: the PR stabilizes one regression assertion after INSERT OVERWRITE plus REFRESH MATERIALIZED VIEW ... AUTO. The changed block still checks direct MTMV cache invalidation, still checks nested rewrite cache invalidation, verifies the refreshed MTMV is chosen with SQL cache disabled, and compares cache-enabled vs cache-disabled results.
• Scope: the change is small and focused to one regression-test assertion block.
• Concurrency, lifecycle, config, compatibility, persistence, FE/BE protocol, data-write behavior, and observability: not applicable to this regression-only change.
• Parallel paths: checked the nearby AUTO refresh, complete refresh, add-partition/base-insert, and add-column branches in the same suite; I did not find a missed analogous assertion change.
• Session state: mv_rewrite_success checks the memo plan contains the refreshed MV choice, and judge_res restores enable_sql_cache=true plus enable_strong_consistency_read=true before later cache assertions.
• Test result files: no .out files are changed. I did not run the regression suite in this review-only checkout; .worktree_initialized and thirdparty/installed are missing.
• User focus: no additional user-provided review focus was present.

Round 1 full-review and risk-focused subagents both returned NO_NEW_VALUABLE_FINDINGS; the main risk scan items were dismissed with code evidence.