Let kernel own default telemetry enabled state

[jay-xiao446]

Summary

• pass through explicit enable_telemetry values to the kernel
• omit telemetry_enabled from kernel Session kwargs when the user does not specify enable_telemetry
• update tests to assert the unset/None case lets the kernel default apply

Validation

• python3.12 -m py_compile src/databricks/sql/backend/kernel/client.py src/databricks/sql/session.py tests/unit/test_session.py tests/unit/test_telemetry.py tests/unit/test_kernel_client.py
• git diff --check

[peco-review-bot]

Verdict: 1 Low

Looks good — the omit-when-None telemetry threading is internally consistent (session.py forwards raw enable_telemetry, client.py omits it when None) and the tests are updated to match. One low-severity note: this reverses a formerly-deliberate kernel default-OFF divergence, and the resulting default is now whatever the opaque kernel picks — worth confirming it matches the intended posture.

[peco-review-bot]

🔵 Low — This reverses a previously-deliberate divergence: the removed comments here and in client.py stated the kernel path intentionally defaulted telemetry to OFF ("Do not 'fix' this back to True to match the other backends"). By omitting telemetry_enabled when unset, the effective default is now whatever the Rust kernel picks. If the kernel's internal default is ON (to match the connector-wide True default at client.py:435), this silently flips unset-telemetry from off→on for use_kernel=True — a behavior change no unit test can catch, since the tests only assert the key is omitted, not the resulting kernel behavior. Worth confirming the kernel's default matches the intended privacy posture before merge, and ideally noting the expected default in the comment so a future reader isn't left guessing. Not blocking — the PR title indicates this hand-off is intentional — but the loss of the explicit assertion means the actual default is now unverified in this repo.