[yahyafakhroji]

Problem
Since milo-os/assistant#169 the assistant refuses to send a user's token over plain http. compute-mcp only served http on port 8080, so on staging the assistant drops every compute tool and logs credential_plaintext_refused for compute-mcp.

Solution
compute-mcp serves https when given --tls-cert-file and --tls-key-file, and reloads the certificate when cert-manager rotates it. Without the flags it still serves http for local dev and e2e, and setting only one fails at startup. The deployment mounts a certificate from the datum-control-plane ClusterIssuer through the cert-manager CSI driver and probes over HTTPS, and all 29 compute-mcp URLs in the capability documents now use https. The assistant already trusts that CA (datum-cloud/infra#8826). Production pins compute at v0.16.0, so it picks this up after a release and a pin bump.

Refs milo-os/assistant#169

[ecv]

Approve.

compute-mcp serves https from a CSI cert whose SANs cover compute-mcp.compute-system.svc.cluster.local, and all three assistant configs (v1, v2, exec v3) now point at https on that host.

• SANs: the CSI dns-names are compute-mcp, .compute-system.svc and .compute-system.svc.cluster.local, the host in the /mcp, /llms-full.txt and runbook URLs of all three config files. compute-mcp is deployed unprefixed in compute-system per infra's identity-forwarding list.
• Trust: the assistant trusts the datum-control-plane CA through SSL_CERT_FILE and datum-control-plane-system-bundle (infra#8826, merged). The compute manager already mounts a CSI cert from the same issuer (apps/compute-system/deployment-control-plane/base/manager.yaml), so the driver exists there.
• Probes are HTTPS on the unchanged named port; infra's networkpolicy-compute-mcp.yaml selects by port number and label, and the staging exec-relay egress policy is unaffected because the CSI mount is node-side. Pod runs as 65532 and fs-group matches.
• serve.go: certwatcher with GetCertificate, failed re-reads keep the old cert, half-configured flags fail at startup in main and in serve, and the shutdown path uses its own 20s timeout since the parent context is already cancelled. Tests cover https, plain http, rotation, unreadable cert and clean shutdown.

Follow-ups:

• No test ties the SANs to the URLs in the three config files; a drift check would catch a future rename.
• Three implementations of the same TLS serve logic now exist (here, dns-operator, NSO internal/mcpserver) with slightly different shutdown handling; consider a shared helper later.