[Enhancement] Reject cross-mode ALTER for materialized view refresh_mode (backport #72380)

[mergify]

Why I'm doing:

What I'm doing:

ALTER MATERIALIZED VIEW SET refresh_mode is restricted to no-op (same mode). Switching between INCREMENTAL and PCT is not supported; the recovery path for changing refresh_mode is drop-and-recreate.

Production:

• AlterMVJobExecutor.alterMVRefreshMode: replace the IVMAnalyzer re-validation block with a single early gate. If the original mode differs from the target mode, throw with a clear error pointing at drop-and-recreate. Same-mode ALTERs still go through the applier so the persisted property and the in-memory currentRefreshMode stay in sync (relied on by the helper-driven test path).
• The IVMAnalyzer.rewrite call here re-walked the MV's defining query to recompute IVM eligibility on every ALTER refresh_mode. Since same-mode ALTER is the only allowed transition under the new gate, that re-validation is no longer reachable; remove it (and the now unused import) to keep the method narrow and avoid a known AST mutation leak in the analyzer's catch-and-fallback path.

Tests:

• testChangeMVRefreshMode1 (AUTO MV): AUTO -> INCREMENTAL now expects rejection (cross-mode). The companion AUTO -> AUTO leg still expects rejection at the PropertyAnalyzer layer (PR2). Mode stays AUTO throughout.
• testChangeMVRefreshMode3 (INCREMENTAL MV): adds a third leg asserting INCREMENTAL -> PCT is rejected, the gap PR6 was created to close.
• testChangeMVRefreshMode2/6/7 already expect failure for their cross-mode legs and continue to pass under the simpler rule.

Fixes #issue

What type of PR is this:

• BugFix
• Feature
• Enhancement
• Refactor
• UT
• Doc
• Tool

Does this PR entail a change in behavior?

• Yes, this PR will result in a change in behavior.
• No, this PR will not result in a change in behavior.

If yes, please specify the type of change:

• Interface/UI changes: syntax, type conversion, expression evaluation, display information
• Parameter changes: default values, similar parameters but with different default values
• Policy changes: use new policy to replace old one, functionality automatically enabled
• Feature removed
• Miscellaneous: upgrade & downgrade compatibility, etc.

Checklist:

• I have added test cases for my bug fix or my new feature
• This pr needs user documentation (for new or modified features or behaviors)
  • I have added documentation for my new feature or new function
  • This pr needs auto generate documentation
• This is a backport pr

Bugfix cherry-pick branch check:

• I have checked the version labels which the pr will be auto-backported to the target branch
  • 4.1
  • 4.0
  • 3.5
  • 3.4

---

This is an automatic backport of pull request #72380 done by [Mergify](https://mergify.com).