[fix](regression) Wait for schema change in rewrite_when_dml

[shuke987]

What problem does this PR solve?

Issue Number: None

Related PR: None

Problem Summary:

The rewrite_when_dml regression case waits for MTMV build tasks, but it did not wait for column schema-change jobs after ALTER statements. On Cloud P0, a later ALTER can run while the table is still in SCHEMA_CHANGE and fail with Table[orders]'s state(SCHEMA_CHANGE) is not NORMAL.

This patch waits for the latest column schema-change job to finish after each ALTER in this case before continuing with MV rewrite checks.

Release note

None

Check List (For Author)

• Test

  • Regression test
  • Unit Test
  • Manual test (add detailed scripts or steps below)
    • git diff --check
  • 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

[shuke987]

run buildall

[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]

/review

[github-actions]

Automated review completed for PR 65408.

I did not find a blocking issue or any substantiated inline-comment candidate. The change is a narrow regression-test stabilization: after each ALTER TABLE ... ADD/DROP COLUMN, the suite now waits for the latest column schema-change job to finish before creating/checking MTMV rewrite behavior. This matches the established waitForSchemaChangeDone { SHOW ALTER TABLE COLUMN ... ORDER BY CreateTime DESC LIMIT 1 } pattern, and the helper issues SYNC before the later explain/query checks.

Critical checkpoint conclusions:

• Goal/test proof: the PR addresses a test race in rewrite_when_dml.groovy; the suite itself is the regression coverage.
• Scope: the modification is small and limited to the affected test.
• Concurrency/lifecycle: no new product concurrency or lifecycle path is introduced; the added waits serialize the existing asynchronous schema-change jobs before dependent checks.
• Configuration/compatibility/persistence/protocol: no new config, persisted format, or FE/BE protocol surface is changed.
• Parallel paths: all three schema-change points in this suite now wait before MV rewrite validation.
• Test/result correctness: no .out artifact is expected for this suite; the added waits do not change query results.
• Observability/performance: no new runtime path or observability requirement is introduced.

User focus: no additional user-provided review focus was supplied.

Subagent conclusions: optimizer-rewrite found no optimizer semantic-equivalence or parallel join/aggregate issue; tests-session-config found no test/session/config/style issue. Final convergence round 1 ended with both live subagents replying NO_NEW_VALUABLE_FINDINGS for the same empty proposed inline-comment set.

Validation note: review was static. The checkout is shallow and not worktree-initialized, with thirdparty/installed absent, so I did not run the regression suite locally.

[shuke987]

run buildall