Fix Snowflake SQL API wait_for_query timing out on finished queries

[KarthikMohankumar]

SnowflakeSqlApiHook.wait_for_query checked the elapsed time before it looked at the status it had just fetched. If the status call itself returned after the timeout, the method raised TimeoutError even when that status showed the query had already finished (success or error).

This is easy to hit in practice. Each status call goes through _make_api_call_with_retries, which retries 429/503/504 and connection errors with exponential backoff, so one call can take several seconds. The only caller in the provider, the OpenLineage helper _run_single_query_with_api_hook, uses timeout=3. A slow but successful status check therefore surfaced as a timeout, and the query-history details for lineage were dropped.

Changes:

• the status is checked first; TimeoutError is raised only while the query is still running
• elapsed time uses time.monotonic() instead of time.time(), so wall-clock adjustments (NTP sync, DST) cannot cut the wait short or stretch it

Tests:

• new test_wait_for_query_returns_finished_status_after_timeout_elapsed (parametrized for success and error): a single status call that takes longer than the timeout returns the finished status instead of raising. It fails with the previous check order.
• test_wait_for_query_timeout_error now drives a fake monotonic clock, because time_machine does not move time.monotonic(). It still asserts the same number of polls and sleeps before TimeoutError.

Checks run locally:

• uv run --project providers/snowflake pytest tests/unit/snowflake/hooks/test_snowflake_sql_api.py: 91 passed
• uv run --project providers/snowflake pytest tests/unit/snowflake/utils/test_openlineage.py: 48 passed
• prek run --stage pre-commit on the changed files: 45 hooks passed. check-provider-yaml-valid needs the Breeze CI image and could not run locally (no provider.yaml change here); ast-grep was skipped because it could not download its Node runtime.

---

Was generative AI tooling used to co-author this PR?

• Yes — Claude Code (Opus 5.5)

Generated-by: Claude Code (Opus 5.5) following the guidelines

[justinpakzad]

Thanks for the PR, the change makes sense to me.

[potiuk]

The ordering fix is right: a query that already finished is reported even when the status call itself ran past the timeout, and a query still running past the timeout still raises. time.monotonic() is the right clock for this, and mocking it is needed since time_machine doesn't control the monotonic clock. Thanks!

---

Drafted-by: Claude Code (Opus 5.5); reviewed by @potiuk before posting