fix(db-snowflake): resolve timeoutMs 0 to the default, matching BigQuery

[girishjeswani]

Summary

The Snowflake connector treated a configured timeoutMs of 0 as "wait
forever", which is inconsistent with the BigQuery connector. In
#3010 BigQuery's 0 was aligned to fall back to the default;
this does the same for Snowflake, so a 0, a negative value, or a blank /
non-numeric value (parsed to NaN) now resolves to the 10-minute default.

Root cause

timeoutMs is resolved in the connection constructor with
options?.timeoutMs ?? TIMEOUT_MS, so ?? only defaults null/undefined and
keeps an explicit 0. That 0 then reaches the executor's
timeoutMs ? setTimeout(cancel, timeoutMs) : undefined, where a falsy value
schedules no timer, i.e. no client-side timeout. A blank or non-numeric
connection value is parsed to NaN by parseInt in index.ts, which is also
falsy and behaves the same way. A negative value, by contrast, is truthy, so it
reaches setTimeout(cancel, <negative>) and aborts the statement almost
immediately.

Change

• Resolve to a positive number or the default: unset, blank, non-numeric, zero,
  and negative all fall back to the 10-minute default, and only a positive value
  overrides it. Uses Number(...) > 0 rather than a bare ||, because a
  negative value is truthy and would otherwise reach setTimeout(cancel, <negative>) and abort the statement at once. Matches the BigQuery connector,
  and applies to both timeoutMs and the sibling schemaSampleTimeoutMs.
• No other behavior changes. The per-statement client-side cancel is unchanged:
  on timeout the executor already calls statement.cancel(), which cancels the
  running query server-side. The per-statement model (each statement in a batch
  bounded by timeoutMs) is retained.

Scope

Snowflake-only, and intentionally minimal. This is the consistency follow-up
requested on #3010; it does not add a server-side job timeout.
Snowflake's STATEMENT_TIMEOUT_IN_SECONDS (the server-side cap, analogous to
BigQuery's jobTimeoutMs) is left unset, as today. Shadowing timeoutMs to it
is a reasonable future addition if a per-job rather than per-statement bound is
wanted, but it is a larger change (seconds granularity, session-vs-statement
scoping) and is deliberately out of scope here.

Tests

There is no new unit test. The resolution is a two-line guard
(Number(...) > 0 ? ... : TIMEOUT_MS) whose comment documents intent; a test
for it could only go red if the test and the guard were edited together, so the
guard and its comment stand on their own. The existing live integration test
(cancels long-running batch on timeout, timeoutMs = 500) exercises the
client-side cancel and is unaffected, since a positive value still passes
through.

tsc and eslint pass.

Notes

• Behavior change worth flagging: a timeoutMs of 0 previously disabled the
  client-side timeout (unbounded) and a negative value cancelled the statement
  almost immediately; both now use the 10-minute default. After this there is no
  value that means "no timeout"; that is intentional and matches the BigQuery
  connector.

Checklist

• Companion docs update: docs(config): clarify Snowflake timeoutMs semantics malloydata.github.io#337 updates the
  Snowflake timeoutMs row (default, per-statement, 0 falls back to the
  default).

[mtoy-googly-moogly]

the test reaches into privates through a cast and asserts by argument position, so it breaks on refactors unrelated to timeouts while pinning a two-line guard the comment already explains.

just delete it