[hello-stephen]

What problem does this PR solve?

The rolling-upgrade regression runs these suites once during initialization and again with -w after each upgrade stage. Initialization updates and deletes rows in the fixtures and enables UPDATE_FLEXIBLE_COLUMNS. Repeating the original test then compares the final data against the initial snapshot, or attempts to enable an already-enabled feature, before checking compatibility.

Keep the original initialization path unchanged. During -w verification, compare the complete ordered persisted fixture against fixed reference SQL and verify the flexible-update table property for both row-store variants. This path performs no writes, table recreation, or reload, so corrupted, missing, and additional persisted rows remain failures. Existing generated output files remain unchanged.

Scope: subsequent upgrade stages verify persisted-data and feature-metadata compatibility. They no longer replay this suite's initialization DML; this change does not establish mixed-version write coverage or binary downgrade support.

Release note

None

Check List (For Author)

• Test: git diff --check; isolated Groovy syntax/suite-registration and control-flow harness, covering unchanged initialization call traces, both row-store tables, three repeated read-only verification runs, and rejection of corrupted/missing/additional rows and a disabled feature property. This is not a Doris cluster runtime test; rolling-upgrade validation remains pending with case artifacts containing this fix.
• Behavior changed: Yes, -w checks the persisted final fixture instead of replaying initialization operations.
• Does this need documentation: No

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

[yiguolei]

run buildall