fix: serve a leaf certificate, not the CA

LibreChat served the lab CA's own certificate as its server certificate — a
CA:TRUE certificate valid for the whole *.sttlab.local wildcard, from a
hand-made tls.yaml that also carried the CA's private key. Gitignored, so never
leaked, but the only service in the estate still copying the CA around instead
of being issued a leaf.

Now a cert-manager Certificate for librechat.sttlab.local: CA:FALSE, one
dnsNames, key generated in the cluster and rotated there.

The two uses of that Secret had to be separated first, which is the part worth
knowing: sttlab-tls was both the ingress certificate and the CA bundle mounted
as NODE_EXTRA_CA_CERTS for outbound calls. Replacing it with a leaf alone would
have left LibreChat unable to verify Keycloak. The CA certificate now comes from
ca-configmap.yaml — the certificate, never the key, committed like the agents'.

Verified: the ingress serves CA:FALSE with SAN librechat.sttlab.local, the pod's
outbound call to Keycloak returns 200 with TLS verified, and the old secret is
deleted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

k8s/ingress/certificate.yaml

@@ -0,0 +1,21 @@
+# cert-manager issues this into the `librechat-tls` Secret.
+#
+# It replaces a hand-made `tls.yaml` that carried the lab CA's own certificate
+# and private key, which LibreChat then served as its server certificate — a
+# CA:TRUE certificate valid for the whole `*.sttlab.local` wildcard, where a
+# leaf for one name is what a server needs.
+#
+# The key is generated in the cluster, rotated by cert-manager, and never
+# reaches a file anyone has to remember not to commit.
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: librechat-tls
+  namespace: librechat
+spec:
+  secretName: librechat-tls
+  dnsNames:
+    - librechat.sttlab.local
+  issuerRef:
+    name: sttlab-local-ca
+    kind: ClusterIssuer