[test] Bound the level 0 compaction wait in PrimaryKeyFileStoreTableITCase

[wombatu-kun]

Purpose

PrimaryKeyFileStoreTableITCase can hang until the 120-minute cap of the "UTCase and ITCase Flink 2.x on JDK 11" job. Since GitHub reports a job timeout as CANCELLED rather than a failure, and a killed job leaves behind neither a surefire report nor artifacts, this reads as if someone had cancelled the run. It happened twice on clean master in the last two days, in https://github.com/apache/paimon/actions/runs/30420293991 and https://github.com/apache/paimon/actions/runs/30327861765, and once on the unrelated PR #8923, in https://github.com/apache/paimon/actions/runs/30515132005. In each case this class was the only one that logged Running ... and never reported completion, against a normal runtime of about 537 s for its 30 tests. Re-running that same job on the unchanged #8923 commit passed, which is what identifies this as a flake in the test rather than a regression from the code under review.

The unbounded wait lives in checkBatchResult. #7036 added a while (true) loop that waits until T$files reports no level 0 files, for tables where needLookup() holds, that is a lookup changelog producer or deletion vectors. If compaction never completes, the loop spins forever: in testStandAloneLookupJobRandom the table is write-only and compaction is performed by a separate CompactAction job, so a dead compactor makes the condition unsatisfiable. @Timeout(180) does not rescue the test, because JUnit 5.8.1 in SAME_THREAD mode delivers a single Thread.interrupt(), and the loop spends nearly all of its time inside a Flink job where that interrupt is lost. #4634 had already introduced the collect(result, timeout) watchdog helper for exactly this class of problem, and the next statement in the same method uses it, but the loop added later calls TableResult.collect() directly and bypasses it.

This change bounds the wait by TIMEOUT seconds, routes the query through the existing watchdog helper, and reports how many level 0 files were still present when the deadline expired. A stalled compaction now fails in about three minutes with a message that separates "compaction is dead" from "compaction is slow", instead of consuming the entire CI job. The deadline equals the value these tests are already annotated with, so no test becomes stricter than it was meant to be.

Tests

Ran the eight *Random tests that reach checkBatchResult under -Pflink2 on JDK 11: Tests run: 8, Failures: 0, Errors: 0 in 149 s.

Negative check, to confirm the deadline actually fires instead of being dead code: with the loop condition temporarily made unsatisfiable and the deadline shortened, the test failed after 46 s with java.util.concurrent.TimeoutException reporting 16 remaining level 0 files, rather than hanging. That temporary modification is not part of this PR.

[JingsongLi]

+1