[Fix][Zeta] Fix flaky pending job info test

[QuakeWang]

Purpose of this pull request

Fix flaky CoordinatorServiceTest.testGetPendingJobInfo.

Related CI failure: https://github.com/QuakeWang/seatunnel/actions/runs/25901176569/job/76125357474

The old test submitted a real job and asserted that the job was still in pendingJobQueue. This assertion depended on a transient scheduler state because the coordinator scheduler may consume the pending job immediately after submission.

This patch makes the test deterministic by constructing a controlled pending job and verifying that getJobInfo() can return DAG info from the pending job path.

Does this PR introduce any user-facing change?

No.

How was this patch tested?

git diff --check
./mvnw -pl seatunnel-engine/seatunnel-engine-server -am -Dtest=CoordinatorServiceTest#testGetPendingJobInfo -DfailIfNoTests=false -DskipIT=true -Dskip.spotless=true verify

Check list

• If any new Jar binary package adding in your PR, please add License Notice according
  New License Guide
• If necessary, please update the documentation to describe the new feature. https://github.com/apache/seatunnel/tree/dev/docs
• If necessary, please update incompatible-changes.md to describe the incompatibility caused by this PR.
• If you are contributing the connector code, please check that the following files are updated:
  1. Update plugin-mapping.properties and add new connector information in it
  2. Update the pom file of seatunnel-dist
  3. Add ci label in label-scope-conf
  4. Add e2e testcase in seatunnel-e2e
  5. Update connector plugin_config

[DanielLeens]

Thanks for the contribution. I reviewed the latest head and checked the pending-job path that this test is targeting. This change is test-only, it hits the real pending-queue branch, and I do not see a source-level blocker on the current head.

What this PR solves

• User pain point
  Pending-job tests that depend on coordinator scheduling timing can fail intermittently, which makes it hard to tell whether the failure is in production logic or in the test itself.
• Fix approach
  This PR rewrites the test setup to construct pending-job scenarios directly with helpers instead of depending on asynchronous timing.
• One-line summary
  This is a focused test-stability fix for the pending-job path, and I do not see a source-level blocker on the latest head.

Runtime path I checked

CoordinatorService.getJobInfo(jobId) [CoordinatorService.java:1393-1407]
  -> history lookup
  -> runningJobMasterMap lookup
  -> pendingJobQueue.getById(jobId)
  -> runningJobInfoIMap lookup

Key findings

1. The production path itself is unchanged.
2. The updated test now targets the real pendingJobQueue branch directly instead of relying on async scheduling to reach that state.
3. The new helpers (newMockCoordinatorService(...), enqueueMockPendingJob(...)) make the scenario easier to reason about and less timing-sensitive.
4. I do not see a source-level blocker on the latest head.

Test / CI notes

• The test structure is healthier than before: it uses mocks and condition-based waiting rather than adding new fixed sleeps.
• The current Build signal is incomplete because the latest run was cancelled, and changes did not finish cleanly before the matrix fan-out, so CI needs a clean rerun before merge.

Conclusion: can merge after fixes

1. Blocking items

• Please rerun the latest CI and get Build green before merge.

2. Suggested but non-blocking improvements

• No new source-side changes are required from my side on this revision.

Overall, this looks like a good test-only cleanup for the pending-job path. I do not have a source-level blocker on the current head; the remaining gate is CI completeness.