bug(nats): explicit tls: null in HelmRelease values panics the template #3611

packages/apps/nats/templates/_tls.tpl:12 reads .Values.tls.enabled directly to implement the tri-state. Helm coalescing treats an explicit null as a deletion rather than a request for the chart default, so a HelmRelease sending tls: null wipes the tls: {} default at values.yaml:79 and leaves .Values.tls nil. helm template nats packages/apps/nats --values <file with tls: null> fails with executing "nats.tls.enabled" at <.Values.tls.enabled>: nil pointer evaluating interface {}.enabled.

A tenant whose generated values carry an empty tls key, which is what an API layer emitting all fields including unset ones produces, gets a HelmRelease that never renders, so the release just sits failing on a template error.

Guarding the lookup with a nil-safe read fixes it in one line, and a unit test rendering with tls: null pins it. Worth checking the sibling tri-state helpers for the same dereference, packages/apps/qdrant/templates/_helpers.tpl has the same construct.