chore: refactor CI to have centralized SBT action

[comphead]

Which issue does this PR close?

Closes #.

CI: split Spark SBT compile from test execution

Problem

sql_core-* matrix entries randomly SIGKILL on Spark 4.1.2 runners with Killed (no JVM stack) — the kernel/container OOM killer, not -Xmx exhaustion. Each matrix entry runs sbt -mem 3072 testOnly *, so SBT pays the full Scala/Zinc compile heap (~2.5–3 GB peak) and then orchestrates the forked test JVM, on top of Comet's native off-heap pool, on a 7 GB hosted runner. The budget is at the
edge; cumulative allocation patterns push it over non-deterministically.

Change

• New single build job per Spark version: builds libcomet.so (cargo --profile ci) and runs sbt -mem 3072 catalyst/Test/compile sql/Test/compile hive/Test/compile once. Uploads two
  artifacts:
  • native-lib-linux (libcomet.so, ~50 MB)
  • jvm-compiled-spark-<full>-jdk<N> (apache-spark.tar.gz, sources + target/ + Zinc state, ~500 MB–1 GB, mtimes preserved via tar -czpf)
• Matrix spark-sql-test entries needs: build, download + extract both, call setup-spark-builder with skip-spark-clone: true (only re-runs the mvn install of Comet's JAR), then sbt -mem 1536 testOnly *. Zinc verifies "no source changed" and skips compile.
• setup-spark-builder gains a skip-spark-clone input to gate the Spark checkout + diff apply when sources are pre-staged from the artifact.

Effect

• SBT heap per matrix runner: 3072 → 1536 MB, freeing ~1.5 GB of runner headroom — the budget gap that was producing the OOM kills.
• Spark compile runs once per Spark version instead of seven times per matrix.
• One fewer runner per Spark version: was build-native + 7×(compile+test) = 8; now build (native + compile) + 7×test = 8 — same job count, but the heavy compile is amortized.