RoutingClient: no TLS support, and a constructor signature that diverges from Client

[ramakrishnap-nv]

Summary

cuopt.grpc.routing.RoutingClient diverges from the LP/MIP cuopt.grpc.linear_programming.Client in two ways that look like an oversight rather than a deliberate design choice, found while writing #1838's docs.

Evidence this was missed, not decided

• Client's TLS support (tls=None/False/TlsConfig, PR Python grpc async api allow arguments for TLS #1525) landed 2026-07-10 -- over 5 weeks before RoutingClient was added in PR Routing over gRPC: VRP server + compiled C++/Cython client #1597 (2026-08-18). RoutingClient was the newer of the two, not the older one TLS was never backported to.
• RoutingClient.__cinit__ already reuses the exact same C++ shim as Client (grpc_python_client_t), which already supported a grpc_python_client_connect_options_t overload for TLS at the time Routing over gRPC: VRP server + compiled C++/Cython client #1597 was written -- it just calls the plain 2-arg constructor instead of that overload.
• Routing over gRPC: VRP server + compiled C++/Cython client #1597's own PR description explicitly calls out its one deliberate scope cut ("VRP is unary-only (no >2 GiB chunking yet), matching the server POC" -- tracked separately in VRP gRPC: chunked upload/download for large problems and solutions #1629) but says nothing about TLS or the constructor signature.
• Routing over gRPC: VRP server + compiled C++/Cython client #1597's review thread has an exhaustive list of every follow-up filed from that review (VRP gRPC: chunked upload/download for large problems and solutions #1629, VRP gRPC: log streaming and incumbent parity with LP/MILP #1630, VRP gRPC: server-side validation of routing problem inputs #1631, VRP gRPC client completeness: settings surface, e2e coverage, docs, perf nits #1632, Generate cuopt_routing.proto and VRP mapper via field_registry codegen #1616) -- neither TLS nor the constructor signature appears anywhere in the PR's comments (checked via the GitHub API, zero matches for "TLS" or "host"/"port"/"constructor" across all review comments).

Gaps

1. TLS -- RoutingClient.__cinit__(target="host:port") calls grpc_python_client_t(host, port), the 2-arg constructor, whose tls_mode defaults to ENV. So it does pick up CUOPT_TLS_* env vars the same way Client's default tls=None does, but there is no way to pass tls=False (plain TCP, ignore env) or an explicit TlsConfig (custom CA / mTLS) the way Client(host, port, tls=...) allows.
2. Constructor signature -- RoutingClient(target: str = "localhost:50051") takes one "host:port" string; Client(host: str, port: int, *, tls=None) takes two args plus the keyword-only tls. Copy-pasting between the two client docs/examples is an easy mistake.

Proposed fix

Mirror Client.__init__ exactly: RoutingClient(host: str, port: int, *, tls=None), reusing the existing _connect_options_from_tls() helper and the TLS-options grpc_python_client_t constructor overload already used by Client. This is a signature change (not additive), so it needs a decision on whether RoutingClient has any external users yet to consider for compatibility, or whether it's safe to change outright pre-wide-release.

Related: #1632 (client completeness -- settings surface, docs), #1629 (chunking, separately tracked and already correctly scoped).