[Fix][Transform-V2] Align Scala compiler with Spark Scala version - #11117

Thanks for the contribution. I reviewed the full current diff from the real dynamic Scala compile path, not just the POM cleanup.

What this PR fixes

• User pain: seatunnel-scala-compiler was pinning its own Scala version to 2.13.11 while the repository root and Spark-facing baseline are still on 2.12.15, so the shaded compiler used by ScalaClassParser could drift away from the runtime Scala baseline.
• Fix approach: remove the local Scala version override from seatunnel-scala-compiler, let it inherit the root scala.version, switch ScalaClassParser to the constructor path that matches the current compiler version, and add a CI guard that prevents the module from silently diverging again.
• One-line summary: the fix aligns the compiler module back to the repository-wide Scala baseline, and I did not find a source-level blocker in the latest head.

Runtime path I checked

dynamic compile transform
  -> ScalaClassParse.parse(...)
      -> ScalaClassParser.parseSourceCodeWithCache(...)
          -> static IMain initialization
          -> scalaInterpreter.compileString(sourceCode)
          -> scalaInterpreter.classLoader().loadClass(className)

Key findings

1. The normal path really does hit this change. ScalaClassParser is the actual runtime bridge for dynamic Scala transform compilation.
2. Removing the local scala.version=2.13.11 override and inheriting the root pom.xml Scala baseline is the right direction here. It eliminates a silent split between the shaded compiler module and the rest of the build.
3. The new ScalaCompilerVersionCheckTest is useful because it protects the build contract from drifting again.
4. My only remaining gap is test shape, not source correctness: the new test guards the POM/dependency contract, but it does not directly execute a minimal ScalaClassParser compile path yet.

Other reviewer / maintainer input

• There were no prior non-Daniel reviews or comment threads on this PR when I reviewed it, so there was nothing to de-duplicate here.

Testing / stability

• The new test is structurally stable: pure file/XML inspection, no timing, ports, threads, or external services.
• I did not run local Maven in this batch; this is a source-level PR review only.
• GitHub Build was still in progress when I reviewed.

Merge conclusion: can merge

1. Blocking items

• None from my side at the source level.

2. Suggested follow-up

• A small follow-up runtime smoke test that actually drives ScalaClassParser.parseSourceCodeWithCache(...) on a trivial Scala snippet would make this even stronger, because the current new test only guards the version contract, not the end-to-end compile path.

Overall, this is a focused and defensible fix. The main runtime path is real, the version alignment is materially better than before, and I do not see a source-level reason to block merge on the current head.

+1
LGTM
Thanks for your contribution!