fix: drop clustering key before dropping columns it references

[srujankgandla]

Description

Fixes #5813.

When a model removes both a column and its clustered_by in the same edit, the non-breaking path clones the table (the clone inherits the clustering key) and then issues ALTERs. ClusteredByMixin.get_alter_operations appended the drop/replace clustering-key operation after the column alterations, so Snowflake received DROP COLUMN while the key still referenced it and rejected it with error 003203 — before the key was ever dropped.

This change sequences the clustering-key operation first, so the key is dropped (or replaced) before any column it references is altered. It also fixes the latent twin: changing the key while dropping a column referenced by the old key.

Added test_alter_table_drops_clustering_key_before_drop_column, which asserts the generated statement order on a mocked Snowflake adapter.

Test Plan

• Added test_alter_table_drops_clustering_key_before_drop_column in
  tests/core/engine_adapter/test_snowflake.py: on a mocked Snowflake adapter
  it asserts the generated statements are
  ALTER TABLE "test_table" DROP CLUSTERING KEY followed by
  ALTER TABLE "test_table" DROP COLUMN "b".
• python -m pytest tests/core/engine_adapter/test_snowflake.py -k "alter_table" -q → 2 passed.
• Broader engine-adapter suites for all three ClusteredByMixin consumers
  (Snowflake, BigQuery, StarRocks): 219 passed, 1 skipped; the only 2 failures
  are pre-existing pandas-environment issues that fail identically on the clean tree.
• ruff check and ruff format --check clean on both changed files.

Checklist

• I have run make style and fixed any issues
• I have added tests for my changes (if applicable)
• All existing tests pass (make fast-test)
• My commits are signed off (git commit -s) per the DCO