CAS shared endpoint: evaluate unix-domain socket for the private gRPC upstream #3671

Follow-up to #3628 / PR #3663.

Context

The CAS shared endpoint dispatches each request and proxies native gRPC through an in-process httputil.ReverseProxy to a private native gRPC server. The private listener is currently a TCP loopback socket (127.0.0.1:0), bound at construction, with the proxy dialing it over h2c.

A benchmark comparison on a 1 GiB ByteStream transfer (2 runs per direction, disk-backed staging) measured the proxy's upstream transport:

UDS recovers roughly 2–4 percentage points of the proxy hop relative to the direct native baseline (the proxy on TCP loopback is −9.0% upload / −8.1% download; on UDS it is about −3.4% / −5%). Heap is identical on both, so end-to-end backpressure is unaffected by the transport choice. The current TCP loopback default already sits inside the R-003 10% shape.

Proposal

Evaluate switching the private listener to a unix-domain socket, or making it an opt-in, only if the measured gain justifies it for a target deployment.

Constraints to weigh:

• The CAS pod runs with readOnlyRootFilesystem: true, so a unix socket must live on a writable mount (the staging emptyDir), and needs lifecycle (create/remove) and permission handling.
• Unix sockets are not supported on Windows (dev machines are Linux/macOS; the server runs in Linux containers, so this is likely fine).
• TCP loopback needs no writable path, no cleanup, no permission handling, and works everywhere.

Scope

• Decide whether the ~2–4 point recovery is worth the deployment complexity.
• If yes: parameterize the private listener network/address (benchmark variant exists on the PR feat(cas): shared HTTP and gRPC endpoint via per-request dispatch and a reverse proxy to the native transport #3663 branch history) and place the socket on a writable pod-local volume.
• Re-run the R-003 transport comparison through the real ingress before adopting.

Refs #3628, PR #3663.

AI assistance: Claude Code.