[Fix][Zeta] Set SeaTunnel home in cluster startup script

[davidzollo]

Purpose

Fixes #10782.

The cluster startup scripts need to publish the effective SeaTunnel distribution home to the server JVM. Without that, cluster-side code that relies on seatunnel.home / SEATUNNEL_HOME can resolve connector metadata and connector jar storage relative to the launch working directory instead of the distribution directory, so connectors under ${SEATUNNEL_HOME}/connectors can be missed.

This fix intentionally does not add ${APP_DIR}/connectors/* to the server JVM global classpath, so connector classloader isolation is preserved.

Changes

• Default SEATUNNEL_HOME to the script distribution directory in both Unix and Windows cluster startup scripts when it is not already configured.
• Pass both -Dseatunnel.home and -DSEATUNNEL_HOME to the cluster server JVM.
• Preserve externally configured SEATUNNEL_HOME values instead of overwriting them with the fallback.
• Add script-level unit tests that verify fallback home propagation, custom SEATUNNEL_HOME propagation, and Windows .cmd fallback/JVM-option ordering.

Tests

• env JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home ./mvnw -T 3C spotless:apply -pl seatunnel-core/seatunnel-starter -am -nsu -Dmaven.gitcommitid.skip=true
• env JAVA_HOME=/Library/Java/JavaVirtualMachines/jdk1.8.0_171.jdk/Contents/Home ./mvnw -T 3C -pl seatunnel-core/seatunnel-starter -Dtest=SeaTunnelClusterScriptTest -DfailIfNoTests=false test -nsu -Dmaven.gitcommitid.skip=true (Tests run: 3, Failures: 0, Errors: 0, Skipped: 0)

[DanielLeens]

Hi @davidzollo, I pulled this PR locally and reviewed the cluster startup path against the current dev baseline.

Local branch: seatunnel-review-10786
Head reviewed: 62a0ede061b6d1301abd29eb2845c8eed942070d

Runtime path checked:

user starts a Zeta cluster
  -> bin/seatunnel-cluster.sh
      -> resolves PRG_DIR / APP_DIR
      -> sources config/seatunnel-env.sh
      -> defaults SEATUNNEL_HOME to APP_DIR when it is not explicitly set
      -> appends -Dseatunnel.home and -DSEATUNNEL_HOME to JAVA_OPTS
  -> SeaTunnelServer JVM starts
      -> engine/common can read the seatunnel.home system property
      -> cluster-side connector/plugin resolution can use the distribution home

The normal cluster startup path does hit this change. The important property is seatunnel.home, which matches SeaTunnelProperties.SEATUNNEL_HOME. Keeping a user-provided SEATUNNEL_HOME also preserves compatibility.

Local checks performed:

• git fetch upstream pull/10786/head:seatunnel-review-10786 --force: passed.
• git diff --stat upstream/dev...seatunnel-review-10786: 2 files, +129/-0.
• Source search confirmed the engine-side property key is seatunnel.home.
• Local build/tests were not run because this review was code-level/static only.
• GitHub checks observed: Build is failing; Notify test workflow and labeler are passing.

Merge conclusion

Conclusion: can merge after fixes

Blocking items:

1. The PR should not be merged while the GitHub Build check is failing. I could not retrieve the failed job log through the current gh session, but gh pr checks 10786 reports Build as failed.

Non-blocking suggestions:

• A small extra test for the case where SEATUNNEL_HOME is explicitly provided would make the compatibility guarantee even clearer.

Overall evaluation:

The code change itself is focused and correct for the cluster startup path. Once CI is green, I do not see a static code blocker in this revision.