When the kernel backend loads, auto-initialize the kernel's
tracing -> Python logging bridge so `use_kernel=True` users see kernel
logs with no extra setup. Kernel logs land under the
`databricks.sql.kernel` logger (a child of the connector's
`databricks.sql.*` namespace), so an existing
`logging.getLogger("databricks.sql").setLevel(...)` cascades to them.

- `_errors.py` calls `databricks_sql_kernel.init_logging()` once at
  extension load (it's the canonical kernel-import site). The call is
  `getattr`-guarded so an older kernel wheel without the function still
  works — just without kernel logs.
- e2e tests assert kernel records reach the `databricks.sql.kernel`
  logger (and the pyo3 boundary under `databricks.sql.kernel.pyo3`) and
  that the level set on the logger is respected. Creds-gated per the
  existing kernel e2e convention.

Requires the companion kernel/pyo3 change
(databricks-sql-kernel#120) that exposes `init_logging()`.

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

Review feedback from PR #824 (gopalldb):

- P1: guard the init_logging() call against throwing, not just a missing
  function. A panic across the PyO3 boundary surfaces as
  pyo3_runtime.PanicException (a BaseException, not Exception), so a bare
  call could escape module import and fail every use_kernel=True
  connection over a non-essential logging feature. Wrap in
  try/except BaseException, log a debug breadcrumb, continue. This also
  neutralizes the idempotency concern regardless of the Rust impl.
- P2: soften the level-control test docstring to make clear it asserts
  the effective customer-visible outcome (sub-threshold records don't
  surface), not source-side suppression — caplog filters after the FFI.
- P2: downgrade the databricks.sql.kernel.pyo3 assertion to a soft
  warning so a benign kernel change to the boundary breadcrumb target
  doesn't break the connector e2e suite. The core
  databricks.sql.kernel contract is still hard-asserted.

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

…g bridge

The kernel tracing -> Python logging bridge (init_logging / pyo3-log,
routing under databricks.sql.kernel) landed in kernel #120 — AFTER the
previously-pinned 101aa46 (#118). The kernel-e2e built a wheel without
the bridge, so test_kernel_logs_reach_python_logging failed with
'no records delivered' (assert []).

Bump to f4ee6fe (current kernel main: includes #118, #120, #123, #125).
Verified live against a wheel built from f4ee6fe: the bridge delivers
records to the databricks.sql.kernel logger, and both
test_kernel_logs_reach_python_logging and
test_kernel_log_level_is_respected pass.

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

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

# Conflicts:
#	KERNEL_REV

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