feat(kernel): consume the folded directResults execute()

[msrathore-db]

What

Adapt KernelDatabricksClient.execute_command to the kernel's folded directResults execute() (databricks/databricks-sql-kernel#136), which now returns a single ExecutedAsyncStatement — seeded with the inline result when the query finished within the server inline wait (fast path, zero extra round-trips), or a poll/cancel handle when still running — instead of always blocking to terminal.

The sync path now drives one uniform flow (no hasattr(await_result) arm to feature-detect): register the handle (so cursor.cancel() / close() reach it), then await_result() to drive it to a ready result set — preserving execute()'s blocking contract.

Caller-visible behaviour

cursor.execute() is unchanged for callers (still blocks to a ready result set); this just adapts to the kernel's new single-handle return. Mid-run cancel still works via the _sync_cancellers canceller registered before execute.

Testing

Tested e2e against live warehouses (auto-closing and non-auto-closing): SELECT 1, range(N), and CREATE+count all succeed on both. The kernel maps an auto-closed CLOSED statement to Succeeded, so the connector sees a uniform success regardless of warehouse auto-close behaviour.

This pull request and its description were written by Isaac.

[msrathore-db]

Not needed with the additive kernel approach (databricks/databricks-sql-kernel#140). That PR adds execute_direct() alongside an unchanged blocking execute(), so use_kernel keeps using execute() exactly as today — no client.py change. Verified e2e against the additive kernel on the unchanged upstream/main driver: CREATE commits, close() cheap (no close-drive), mid-run cancel works (258ms, via the existing _sync_cancellers canceller). The await_result adaptation here was only required for the in-place fold (kernel #136, closed).