feat: provide Java trust integration for sandbox TLS interception

[krishicks]

User Story

As an OpenShell sandbox user running Java-based tooling, I want Java processes to trust the sandbox's TLS interception CA automatically, so that tools such as Bazel can download dependencies without disabling TLS inspection.

Problem Statement

OpenShell generates a self-signed, per-sandbox CA for HTTPS inspection and provides the public certificate as PEM files. It configures trust environment variables for Node, Deno, OpenSSL/Python, curl, and Git, but it does not provide or configure a Java-compatible truststore.

Java clients that use a JDK-owned truststore, including Bazel's embedded JDK, therefore fail inspected HTTPS requests with errors such as:

PKIX path building failed: unable to find valid certification path to requested target

Setting tls: skip is not a general workaround. OpenShell rejects policies where the same host and port are inspected for one binary but use TLS passthrough for another because the endpoints have conflicting connection metadata. This occurs for common dependency hosts such as github.com, release-assets.githubusercontent.com, and files.pythonhosted.org.

Impact / Why This Matters

Java-based build tools and applications cannot use HTTPS destinations protected by normal OpenShell L7 policy without custom truststore bootstrapping. Operators must either modify every Java image and runtime dynamically or disable TLS inspection for the destination globally.

Image-time certificate installation is insufficient because the CA is generated per sandbox. TLS passthrough also removes method/path enforcement and credential rewriting, and it may conflict with existing inspected policies or provider-derived endpoints for the same host.

This blocks ordinary Bazel dependency resolution in development sandboxes and creates the same integration burden for Gradle, Maven, JVM SDKs, and applications using embedded JDKs.

Proposed Design

When OpenShell enables TLS inspection, Java processes launched in the sandbox should automatically trust the same per-sandbox CA as other supported runtimes. This should work for system JDKs and embedded JDKs without requiring users to change their network policies, bake a sandbox-specific certificate into an image, or manually run keytool after sandbox creation.

The Java trust material must rotate with the sandbox CA, retain the platform's existing public roots, and expose only public certificate material to the workload.

Acceptance Criteria

• A Java HTTPS client can reach an inspected protocol: rest endpoint without a PKIX trust failure.
• Bazel using its embedded JDK can resolve BCR metadata and download HTTPS dependencies without tls: skip.
• Existing L7 method/path enforcement remains active for Java traffic.
• The Java trust material includes existing public roots plus the current sandbox CA.
• Trust material is regenerated or refreshed whenever the sandbox CA changes.
• The sandbox receives no CA private key material.
• Existing Node, Deno, OpenSSL/Python, curl, and Git trust behavior remains unchanged.
• Documentation describes Java trust behavior and any supported configuration surface.

Alternatives Considered

• Set tls: skip for Java dependency hosts. This disables L7 inspection and conflicts with inspected endpoints for the same host and port.
• Bake the CA into the development image. The CA is generated per sandbox, so it does not exist at image-build time and changes across sandbox lifecycles.
• Run keytool from each sandbox bootstrap script. This is image- and JDK-layout-specific, is difficult for embedded JDKs, and makes every Java workload reimplement platform trust integration.

Agent Investigation

• SandboxCa::generate creates a new self-signed OpenShell Sandbox CA.
• The network supervisor writes /etc/openshell-tls/openshell-ca.pem and a combined PEM bundle containing system roots plus the sandbox CA.
• The process supervisor injects NODE_EXTRA_CA_CERTS, DENO_CERT, SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE, and GIT_SSL_CAINFO.
• No Java truststore or JVM trust configuration is currently injected.
• Java's JDK-owned truststore does not consume SSL_CERT_FILE, producing the observed PKIX failure.
• Endpoint validation correctly rejects mixing inspected TLS and tls: skip for the same host and port, so binary-specific passthrough cannot solve shared dependency hosts.