GeezerVison

What changes were proposed in this pull request?

Closes #746. This adds a "Preparing Input DataFrames" section to the Configurations page, as suggested in the issue:

• The Growing Lineage Problem: a GraphFrame keeps the input DataFrames together with their full logical plan. Algorithms build every query on top of them, often reference them several times per query, and join them again in every iteration. A long input pipeline is therefore planned again, and recomputed unless it is cached, again and again. The section lists the typical symptoms and explains why the algorithms' own checkpointInterval does not fully solve this.
• Recommendation: Materialize Complex Inputs: Scala and Python examples that checkpoint the vertices and edges before building the graph, plus a table comparing checkpoint(), localCheckpoint(), writing to a table or files and reading them back, and persist()/cache(). The last one avoids recomputation but does not truncate the lineage. It also covers Spark Connect and when materializing is not worth it.
• Cross-link: a link to the new section from the existing "Notes on Configuration Usage" list.

Why are the changes needed?

Users who pass DataFrames produced by complex transformations to GraphFrame(vertices, edges) can see very slow planning, or planning failures, without any hint in the docs about the cause or the fix (#746).

Does this PR introduce any user-facing change?

Documentation only.

How was this patch tested?

• codespell (as in CI) is clean on the changed page.
• build/sbt docs/laikaHTML reports no errors for this page. The only error is the existing README link to api/python/index.html, which CI builds in an earlier step.
• A small local experiment backs the recommendation: label propagation on edges built from 30 to 60 chained joins was about 2x faster with checkpoint()/localCheckpoint() inputs than with the raw inputs, while persist() helped less. Because the setup is small and noisy, the docs give no numbers.