fix(backend/kernel): make package importable without the kernel wheel

The +PyArrow CI matrix installs pyarrow but not the
databricks-sql-kernel wheel (the wheel isn't on PyPI yet, and the
[kernel] extra is deferred — see commit 31ca581). The previous
fix gated unit tests on `pytest.importorskip("pyarrow")` but
test_kernel_auth_bridge.py was still pulled into a kernel-wheel
ImportError because:

  src/databricks/sql/backend/kernel/__init__.py
    -> from databricks.sql.backend.kernel.client import KernelDatabricksClient
        -> import databricks_sql_kernel  # ImportError on +PyArrow CI

The eager re-export from `__init__.py` was a convenience that
broke every consumer that only needed a submodule (type_mapping,
result_set, auth_bridge) — they all triggered the kernel wheel
import for no reason.

Fix:
- Drop the eager re-export from `kernel/__init__.py`. Comment
  documents why and points callers (= session.py::_create_backend,
  already this shape) at the direct `from .client import ...`.
- Drop the no-longer-needed `pytest.importorskip("pyarrow")` /
  `importorskip("databricks_sql_kernel")` from
  test_kernel_auth_bridge.py — auth_bridge.py itself has neither
  dep, so the test now runs on every CI matrix variant.
- test_kernel_result_set.py and test_kernel_type_mapping.py keep
  the pyarrow importorskip because they themselves use pyarrow.

Verified locally across the three matrix shapes:
- both pyarrow + kernel installed: 39 pass.
- pyarrow only (no kernel wheel — the +PyArrow CI shape): 39 pass.
- neither: 9 pass (auth_bridge only), 2 modules skip (the others
  use pyarrow).

Co-authored-by: Isaac
Signed-off-by: Vikrant Puppala <vikrant.puppala@databricks.com>

Author: vikrantpuppala

src/databricks/sql/backend/kernel/__init__.py

@@ -6,10 +6,20 @@
 switch its default transport (SEA REST → SEA gRPC → …) without
 renaming this module.
 
+This ``__init__`` deliberately does **not** re-export
+``KernelDatabricksClient`` from ``.client``. Importing ``.client``
+loads the ``databricks_sql_kernel`` PyO3 extension at module-import
+time; doing that eagerly here would make ``import
+databricks.sql.backend.kernel.type_mapping`` (used by tests / by
+``KernelResultSet`` consumers) require the kernel wheel even when
+the caller never plans to open a kernel-backed session. Callers
+that need the client import it directly:
+
+    from databricks.sql.backend.kernel.client import KernelDatabricksClient
+
+``session.py::_create_backend`` already does this lazy import under
+the ``use_sea=True`` branch.
+
 See ``docs/designs/pysql-kernel-integration.md`` in
 ``databricks-sql-kernel`` for the full integration design.
 """
-
-from databricks.sql.backend.kernel.client import KernelDatabricksClient
-
-__all__ = ["KernelDatabricksClient"]

tests/unit/test_kernel_auth_bridge.py

@@ -15,13 +15,11 @@
 
 import pytest
 
-# The kernel backend's result_set + type_mapping modules transitively
-# import pyarrow; the connector's default-deps test job doesn't
-# install pyarrow, so importing the auth_bridge in that environment
-# would fail at module-collection time. Gate the whole module on
-# pyarrow availability — matches the convention the connector uses
-# for pyarrow-dependent tests.
-pytest.importorskip("pyarrow")
+# auth_bridge.py itself has no pyarrow or kernel-wheel deps. The
+# `databricks.sql.backend.kernel` package's __init__.py deliberately
+# does *not* eagerly re-export from .client either (which would
+# require the kernel wheel). So this test can run on the
+# default-deps CI matrix without any extras. No importorskip needed.
 
 from databricks.sql.auth.authenticators import (
     AccessTokenAuthProvider,