Title: IPv6 + TLS connections fail on JVM/Android (OkHttp SNI bug)

[yianding]

Description:

When connecting to a gRPC server via an IPv6 address with TLS enabled, the connection fails on JVM and Android targets.

Root Cause:

kmp-grpc uses OkHttpChannelBuilder internally (Channel.kt), which has a known upstream bug: AndroidNegotiator.configureTlsExtensions() calls
SNIHostName(String) with the hostname, but IPv6 addresses contain : which is not accepted by the SNIHostName String constructor. This causes an
exception during the TLS handshake.

Relevant upstream issues:

• gRPC-okhttp ipv6 addresses not working with TLS grpc/grpc-java#11492 — "gRPC-okhttp ipv6 addresses not working with TLS" (Status: Not planned)
• gRPC-okhttp ipv6 link local scope grpc/grpc-java#9325 — "gRPC-okhttp ipv6 link local scope"

Reproduction Steps:

1. Start a gRPC server with TLS, listening on an IPv6 address (e.g., [::1]:50051)
2. Use Channel.Builder.forAddress("::1", 50051) to create a channel with TLS
3. Attempt any gRPC call
4. Observe connection failure (typically UNAVAILABLE or an exception from SNIHostName)

Expected Behavior:

IPv6 addresses should work with TLS, the same as IPv4 addresses.

Actual Behavior:

Connection fails when using IPv6 addresses with TLS. IPv4 addresses work fine.

Environment:

• kmp-grpc version: 2.0.0
• Target: JVM / Android
• gRPC-Java: 1.76.0 (bundled with kmp-grpc 2.0.0)

Suggested Fixes (one of):

1. Switch from OkHttpChannelBuilder to NettyChannelBuilder on JVM/Android targets (Netty does not have this IPv6 bug)
2. Add an option to let users choose the transport implementation
3. Upgrade the bundled grpc-okhttp dependency and apply a workaround in AndroidNegotiator

Please let me know if you'd like me to contribute a PR. Happy to help.

[TimOrtel]

Thank you for this report. Feel free to provide a PR since right now I have limited time to inspect this issue.

Otherwise I will try to work on this when I find the time.