[fix](regression) Stabilize rowsets timestamp filters

[mrhhsg]

What problem does this PR solve?

Issue Number: None

Problem Summary: The system rowsets regressions used second-level current timestamps as lower bounds for NEWEST_WRITE_TIMESTAMP. In one test, the timestamp was captured after the table was created and could filter out the initial rowset on a boundary race. In the cloud-only scan variant, the timestamp could be equal to the create-table rowset timestamp and unexpectedly include version 0-1. Capture stable lower bounds on the intended side of table creation for each case, so the tests still exercise timestamp filters while avoiding second-level boundary races.

Release note

None

Check List (For Author)

• Test:
  • Regression test: ./run-regression-test.sh --run -d query_p0/system -s test_query_sys_rowsets
  • Regression test: ./run-regression-test.sh --run -d query_p0/system -s test_query_sys_rowsets (200 consecutive runs)
  • Regression test: ./run-regression-test.sh --run -d query_p0/system -s test_query_sys_scan_rowsets (local non-cloud guard path)
  • Regression test: ./run-regression-test.sh --run -d query_p0/system -s test_query_sys_rowsets
• Behavior changed: No
• 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?

[mrhhsg]

/review

[github-actions]

Review result: requesting changes for one test-stability gap.

Critical checkpoint conclusions:

• Goal/test proof: the changed test now captures a stable lower bound before table creation and keeps the expected rowset versions unchanged.
• Scope: the edit is small, but the same timestamp-boundary pattern remains in a parallel rowsets regression.
• Concurrency/lifecycle/config/compatibility/persistence: no product-code, config, protocol, lifecycle, or storage-format changes in this PR.
• Parallel paths: M-1 identifies the remaining cloud-only rowsets scan test path with the same second-level >= now race.
• Test results: PR body reports query_p0/system test_query_sys_rowsets runs including 20 consecutive runs; I did not run local regression here because this checkout has no thirdparty/installed.
• User focus: no additional focus was supplied.

Subagent conclusions: optimizer-rewrite and tests-session-config both reported no candidates in their initial passes. After M-1 was added to the ledger/proposed comment set, convergence round 1 ended with both live subagents replying NO_NEW_VALUABLE_FINDINGS.

[mrhhsg]

/review

[github-actions]

Review completed for PR 65050 at f4c3543.

I did not find any new blocking issue or any new valuable inline comment beyond the existing thread that has already been addressed by the current patch.

Critical checkpoint conclusions:

• Goal and proof: the PR targets second-level NEWEST_WRITE_TIMESTAMP boundary flakiness in the rowsets regressions. The normal rowsets test now captures a lower bound before table creation, preserving the expected rowsets4 output that includes 0-1 through 5-5; the cloud scan variant now waits past the create-table rowset second before capturing the lower bound, preserving the expected rowsets4 output that excludes 0-1.
• Scope and focus: the live GitHub PR file list and compare API show only the two rowsets regression suites. The change is small and focused on timestamp filter stabilization.
• Parallel paths: the sibling cloud-only scan test is now updated, so the existing inline concern about leaving test_query_sys_scan_rowsets.groovy flaky is covered by the current head.
• Tests and expected results: the expected-output files already encode the intended difference between the local and cloud scan variants. I verified the changed queries against those expectations and the BE rowsets scanner path that exposes newest_write_timestamp as a DATETIME from Unix-second rowset metadata.
• Concurrency, lifecycle, configs, compatibility, transactions, and observability: this is regression-test-only code and does not add runtime product state, config, persistence, protocol, or logging behavior.
• Performance: the added 1.1s sleep is limited to the cloud-only regression path and is directly tied to the second-level timestamp boundary being tested.
• Hygiene: git diff --check is clean for the true PR parent-to-head range over the changed files.

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

Subagent conclusions:

• optimizer-rewrite reported NO_NEW_VALUABLE_FINDINGS; no optimizer/rewrite candidate became an inline comment.
• tests-session-config reported NO_NEW_VALUABLE_FINDINGS; no test/config candidate became an inline comment.
• Main merged MAIN-DUP-001 as a duplicate/resolution note for the existing inline thread about the cloud-only sibling test.
• Convergence round 1 ended with both live subagents reporting NO_NEW_VALUABLE_FINDINGS for the same empty proposed final comment set after the last ledger update.

[mrhhsg]

run buildall

[HappenLee]

LGTM

[github-actions]

PR approved by at least one committer and no changes requested.

fixed