orgCABundle: consume key ca-certificates.crt to match NIC's projected trust bundle

Summary

The chart's orgCABundle consumer reads the CA from the ConfigMap key ca.crt (chart/templates/_helpers.tpl, the build-ca-bundle initContainer). NIC's enterprise CA bundle work projects the org CA under a different key, so the two don't line up out of the box.

Context

NIC's enterprise CA bundle epic (nebari-infrastructure-core#307, landed in nebari-infrastructure-core#346) deploys cert-manager trust-manager as a foundational app and projects the operator's org CA cluster-wide as a ConfigMap:

• name: nebari-trust-bundle
• key: ca-certificates.crt
• projected into every namespace (empty namespaceSelector), including software-pack namespaces created later

The intent is that a pack running behind a TLS-inspecting egress proxy just points orgCABundle.configMapName at nebari-trust-bundle and gets working outbound TLS.

Problem

This pack hard-codes the key ca.crt:

# chart/templates/_helpers.tpl (build-ca-bundle initContainer)
cat /etc/ssl/certs/ca-certificates.crt \
    /var/local/org-ca/ca.crt > /shared/combined-ca.crt

So setting orgCABundle.configMapName: nebari-trust-bundle mounts the right ConfigMap but the initContainer looks for a ca.crt entry that does not exist in it -> the org CA is silently absent from /shared/combined-ca.crt, and outbound HTTPS through the proxy still fails with "unknown CA". The pack works only with a hand-rolled ConfigMap that happens to use ca.crt.

Why NIC can't just match ca.crt

trust-manager's Bundle target supports exactly one key per ConfigMap, and the ConfigMap name is derived from the Bundle name (spec.target.configMap has only key + metadata; additionalFormats is JKS/PKCS12 only). It cannot publish the same CA under multiple PEM keys, nor into an arbitrarily-named ConfigMap. So the projected contract is fixed at nebari-trust-bundle / ca-certificates.crt, and consumers need to standardize on that key.

Proposed change

Consume the key ca-certificates.crt instead of ca.crt in the build-ca-bundle initContainer, so pointing configMapName at nebari-trust-bundle works with no extra wiring. ca-certificates.crt is the system-standard filename (matches the base image's own /etc/ssl/certs/ca-certificates.crt this initContainer already concatenates) and is what data-science-pack already consumes.

Options, in order of preference:

1. Switch the hard-coded key to ca-certificates.crt (simplest; one-line change + README/values comment update).
2. Make the key configurable (orgCABundle.key, default ca-certificates.crt) if we want to keep supporting hand-rolled ca.crt ConfigMaps.

configMapName: "" stays the default, so helm template output is unchanged when the feature is off.

Notes

• The pack's existing design comment already cites trust-manager's Bundle CR as the precedent, so this is just aligning the key with what that projection actually writes.
• Companion issue filed on nebi-pack (same key mismatch, its key is ca-bundle.crt). Reference implementation that already uses ca-certificates.crt: data-science-pack.

Start with the build-ca-bundle initContainer in chart/templates/_helpers.tpl and inspect the orgCABundle documentation or values comment for the supported ConfigMap contract. Render the chart with helm template both with orgCABundle disabled and with nebari-trust-bundle configured, then confirm the ca-certificates.crt key is consumed and the default output remains unchanged.