[fix](regression) stabilize colocate column order plan test

[shuke987]

Proposed changes

Pin parallel_pipeline_task_num=1 in the three-table test_colocate_join_of_column_order explain query.

The case already waits for group_column_order3 to become stable, but Cloud P0 history still shows intermittent HAS_COLO_PLAN_NODE: false / INNER JOIN(PARTITIONED) after the wait. The detailed failures share the same plan shape: the first join is planned as a partitioned shuffle, so its output no longer keeps the NATURAL hash distribution needed by the second join's colocate check.

This is driven by physical-plan selection rather than statistics readiness. One sampled failure already executed ALTER TABLE ... SET STATS and still produced the same INNER JOIN(PARTITIONED) plan. Pinning parallel_pipeline_task_num=1 removes the bucket-shuffle downgrade nondeterminism while preserving the original colocate planner coverage.

Testing

• git diff --check -- regression-test/suites/correctness_p0/test_colocate_join_of_column_order.groovy
• Not run: Cloud P0 case rerun is still pending.

[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

[github-actions]

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

[github-actions]

PR approved by anyone and no changes requested.