fix(spark): drop DataFrame temp views after inserting from them

[raams95]

Description

As reported in #6125, every DataFrame insert in the Spark and Databricks (Spark session) adapters registers a temp view (createOrReplaceGlobalTempView / createOrReplaceTempView) that is never dropped. In long-running sessions the views pile up and keep the DataFrames alive on the driver.

The other adapters already clean up their temp tables through the SourceQuery cleanup callback (DuckDB, BigQuery, MSSQL, ClickHouse, Snowflake). This adds the same for Spark and Databricks: the view is dropped with spark.catalog.dropGlobalTempView / spark.catalog.dropTempView once the statement that reads it has run. I used the catalog API rather than DROP VIEW so the drop goes through the same Spark session that created the view. On Databricks this matters because SQL can otherwise go through the SQL connector.

The temp view name is now generated once, outside the query factory, so the cleanup knows what to drop. The generated SQL is the same as before.

Fixes #6125

Test Plan

• Added test_df_source_query_drops_global_temp_view (tests/core/engine_adapter/test_spark.py) and test_df_source_query_drops_temp_view (tests/core/engine_adapter/test_databricks.py). Each one checks that the view is created and queried inside the source query context and dropped when it exits. Both fail on main (drop never called) and pass with this change.
• pytest tests/core/engine_adapter tests/core/test_snapshot_evaluator.py --ignore=tests/core/engine_adapter/integration passes, except test_drop_table_ducklake_no_cascade, which failed once in a parallel run on my Windows machine and passes when rerun on its own (it doesn't touch the Spark/Databricks adapters).
• ruff check, ruff format and mypy are clean on the changed files.
• I haven't run this against a real Spark or Databricks cluster (no Java on this machine), so the tests use mocked sessions.

Checklist

• I have run make style and fixed any issues (ruff and ruff-format pass; mypy and the migrations hook report the same environment-only errors on main on my Windows machine)
• I have added tests for my changes (if applicable)
• All existing tests pass (make fast-test) (no new failures compared to main on my Windows machine; the Windows-only failures on main are unchanged)
• My commits are signed off (git commit -s) per the DCO