feat(kernel): add max connections option

[vuanhphung]

Add experimental WithKernelMaxConnections(n) and forward it through kernel_session_config_set_max_connections. Positive values set the maximum idle HTTP connections retained per host; omission keeps the kernel default of 100.

This mirrors Node's private maxConnections option and Python's _pool_maxsize forwarding. Kernel support landed in databricks/databricks-sql-kernel#311; the matching kernel revision and C header landed in #469.

Published bindings remain at v1.0.0; bump the kernel bindings modules to v1.1.0 before the next driver release.

Tests: make test-kernel.

[peco-review-bot]

✅ No issues identified by the review bot.

[peco-review-bot]

Verdict: 1 Nit

Looks good — a clean, well-scoped addition of the experimental WithKernelMaxConnections option that mirrors the existing kernel-only knobs (validation → config → C setter) with matching unit/DeepCopy/disposition test coverage. Validation rejects non-positive values in validateKernelConfigContext before buildKernelConfig/applyMaxConnections run, so the size_t cast at backend.go:419 can never receive a negative value, and it's consistent with the existing unannotated C.size_t cast at backend.go:490. Only one stylistic nit (shadowing the max builtin); the PR's own note that the module pins must move to the next bindings release before merge is already documented.

Other findings

• ⚪ Nit — max := n (and the analogous max := *k.MaxConnections in internal/config/config.go DeepCopy) shadows the Go 1.21+ predeclared max builtin. Harmless here since it's only used to take an address for the local pointer, but a neutral name like v avoids the shadow. Purely stylistic.

[peco-review-bot]

Verdict: 1 Low

Clean, well-tested addition — the WithKernelMaxConnections path is coherent end-to-end (positive-value validation runs before the value reaches C.size_t, DeepCopy handles the new pointer, and unit coverage exists at every layer). One low-severity doc-drift issue: the bundled KERNEL_REV bump changes the header's session-close contract to "awaited", which leaves the Go CloseSession comment stale. Note also that this "max connections" PR carries a broader kernel ABI update in the header (session_test timeout arg, result-stream canceller, telemetry circuit-breaker) that isn't wired into Go yet — benign for the build, but larger scope than the title implies.

[peco-review-bot]

🔵 Low — This header change flips the documented close contract from best-effort/async to awaited (kernel_session_close now waits for the server-side delete and reports the awaited failure to the caller). But the Go-side CloseSession doc comment in backend.go:785-786 still states the opposite — "Best-effort: the kernel's close is async (see the C header), so an error is logged, not hard-failed" — and explicitly points readers at the C header for justification. That comment is now stale and contradicts the header it cites. Worth updating the CloseSession comment (and reconsidering whether the awaited failure should still be swallowed as best-effort) in lockstep with this ABI change.

[peco-review-bot]

✅ No issues identified by the review bot.

[peco-review-bot]

✅ No issues identified by the review bot.