feat: set Spark job descriptions for iterative algorithms - #898

What changes were proposed in this pull request?

Iterative algorithms now set a Spark job description before triggering the actions of each iteration, so the Jobs and Stages pages of the Spark UI show entries like GraphFrames Pregel: iteration 7 / 20 instead of indistinguishable generic names:

• Pregel.run() sets <prefix>: iteration <i> / <maxIter> per iteration (the / <maxIter> part is omitted when maxIter == Int.MaxValue, as used by algorithms that rely on early stopping) and <prefix>: materializing final result for the final materialization. The prefix defaults to GraphFrames Pregel and is configurable via a new setJobDescriptionPrefix builder method, so concurrent runs in one application can be told apart.
• Pregel-based algorithms (ShortestPaths, LabelPropagation, StructureAwareLabelPropagation, KCore, DetectingCycles) pass their own algorithm name as the prefix.
• All three DataFrame-based connected components paths (two-phase, two-phase AQE, randomized contraction) label their phases as GraphFrames ConnectedComponents [<runId>]: preparing graph / iteration <i> / materializing final result, reusing the run id that already appears in their driver logs so UI entries can be correlated with log lines.
• RandomWalkBase sets <prefix> [<runID>]: batch <i> of <numBatches> per batch — the prefix comes from a base-class override point, and RandomWalkWithRestart reports its own name — and MaximalIndependentSet labels each of its iterations (added on review request).

The caller's job description (a thread-local SparkContext property) is saved before a run and restored afterwards — including when the run fails — via a small JobDescription.withRestoredJobDescription helper in mixins.scala. Only the job description is set, never the job group, so applications that rely on SparkContext.cancelJobGroup for cancellation are unaffected.

Since this lives in the Scala core, it covers every API surface (Scala, PySpark classic, both Spark Connect paths) — the descriptions are set on the JVM driver, where the algorithms execute.

Not covered here, possible follow-ups: the GraphX-backed algorithm paths, single-action algorithms (BFS, AggregateMessages, ...), and exposing setJobDescriptionPrefix through the PySpark/Connect Pregel builders.

Tested by the new JobDescriptionSuite, which uses a SparkListener to assert that per-iteration descriptions are attached to the jobs of Pregel runs (default and custom prefix), a Pregel-based algorithm (ShortestPaths), all three DataFrame connected components paths, MaximalIndependentSet, and RandomWalkWithRestart, and that the caller's description is restored after both successful and failing runs.

Why are the changes needed?

Closes #797. On a long iterative run today every Spark job looks identical in the UI, so there is no way to tell iteration 2 from iteration 40 — or a healthy run from a stuck one — without parsing driver logs.