feat(db-databricks): add a timeoutMs setting that cancels long-running queries

[girishjeswani]

Summary

The Databricks connector had no query timeout: every statement was run and its
results fetched with no client-side bound and nothing to cancel a runaway query.
This adds a timeoutMs connection setting that bounds the wait and cancels the
operation when it is exceeded, bringing Databricks in line with the BigQuery and
Snowflake connectors. The same mechanism also honors Malloy's abortSignal, so
a cancelled query cancels the Databricks operation (it was previously ignored).

Approach

All statements run through a single executeRaw chokepoint
(session.executeStatement(...) then operation.fetchAll()), so the wait is
bounded there:

• Race fetchAll() against a timeoutMs deadline and the caller's
  abortSignal. On either, best-effort operation.cancel() (which cancels the
  statement server-side too) and reject with an actionable error. The operation
  is closed without being awaited on the failure path, so a close() that hangs
  on the same unresponsive connection cannot swallow the timeout.
• Client-side cancel rather than the SDK's server-side queryTimeout: per the
  @databricks/sql docs, queryTimeout is "effective only with Compute
  clusters" and is ignored on SQL Warehouses, which is what this connector
  targets (the path is a SQL warehouse HTTP path). operation.cancel() works
  for both and bounds the actual client wait.
• timeoutMs resolves to a positive number or the default (10 min): unset,
  non-numeric, zero, or negative fall back, matching the BigQuery and Snowflake
  connectors.
• abortSignal is threaded runSQL -> runRawSQL -> executeRaw; an
  already-aborted signal fails fast before a statement is dispatched.

Scope

Databricks-only. This is the third of the timeout follow-ups from
#3010 (BigQuery) and #3022 (Snowflake). The
server-side STATEMENT_TIMEOUT (the SQL Warehouse equivalent of a server-side
cap) is intentionally not set here; the client-side cancel is portable across
warehouses and clusters and already cancels the server statement.

Tests

• databricks_connection.unit.spec.ts stubs the session/operation and uses fake
  timers to exercise behavior that reading the code cannot verify: a query past
  timeoutMs is cancelled with the actionable error; the timeout still fires
  even if closing the operation hangs; a query that finishes in time is not
  cancelled; an abort mid-flight cancels the operation; and an already-aborted
  signal throws before executing.
• The existing live integration spec (databricks_connection.spec.ts,
  env-gated) is unaffected.

tsc, eslint, and the unit spec pass.

Checklist

• Companion docs update: docs(config): document the Databricks timeoutMs setting malloydata.github.io#338 adds a
  Databricks timeoutMs row to config.malloynb.

[mtoy-googly-moogly]

Please delete the it.each block that resolves zero / negative / unset timeoutMs to 600000. It asserts that a ternary is a ternary — it can only go red if someone edits the test and the code together — and it pays for that by advancing fake time 600 seconds. Same note as on #3022.

The rest of the file earns its keep. The timeout, the abort, the already-aborted case, and especially "times out even if closing the operation hangs" are all real behavior you can't check by reading the code.

The rule I'd like applied going forward: if a test can't go red for a reason that isn't "someone edited both sides", don't write it. Either write one that could actually fail, or leave the thing untested — a two-line guard with a comment explaining why it's > 0 is sufficient documentation of intent.

For what it's worth, I checked the two @databricks/sql claims against 1.15.0 and both hold: runAsync is hardcoded to true in executeStatement and marked deprecated, and queryTimeout's own type doc says it's Compute-clusters-only. I also confirmed live that operation.cancel() stops an in-flight fetchAll and that the abandoned promise rejects rather than hanging, so the void fetchAll.catch() is doing real work.