Support templating in env[].valueFrom for release-scoped Secret names

[rojo1997]

Problem

The chart supports injecting Qdrant API keys from an existing Kubernetes Secret through env (also suggested as the workaround in #249 and #346):

env:
  - name: QDRANT__SERVICE__API_KEY
    valueFrom:
      secretKeyRef:
        name: qdrant-secrets
        key: apikey

However, env[].valueFrom is rendered with toYaml only:

{{- range .Values.env }}
  - name: {{ .name }}
    {{- if .valueFrom }}
    valueFrom: {{- toYaml .valueFrom | nindent 16 }}
    {{- else }}
    value: {{ .value | quote }}
    {{- end }}
{{- end }}

As a result, consumers cannot derive the Secret name from the effective Qdrant fullname. A value such as:

env:
  - name: QDRANT__SERVICE__API_KEY
    valueFrom:
      secretKeyRef:
        name: '{{ include "qdrant.fullname" . }}'
        key: apikey

is emitted literally instead of resolving to names such as tenant-qdrant. This is particularly problematic for parent charts and multi-release installations: the parent cannot place a dynamic Helm expression into dependency values, so it must either hard-code a Secret name, require duplicated per-release configuration, or maintain a fork of this chart.

metrics.serviceMonitor.authorization already uses tpl, so the ServiceMonitor can resolve a templated Secret name while the StatefulSet cannot use the same value consistently.

Proposed change

Evaluate valueFrom with the root chart context:

- valueFrom: {{- toYaml .valueFrom | nindent 16 }}
+ valueFrom: {{- tpl (toYaml .valueFrom) $ | nindent 16 }}

Using $ is important because the code is inside range .Values.env; it gives tpl the Qdrant chart root context, allowing qdrant.fullname and .Release to resolve correctly.

After the change, consumers can use:

env:
  - name: QDRANT__SERVICE__API_KEY
    valueFrom:
      secretKeyRef:
        name: '{{ include "qdrant.fullname" . }}'
        key: apikey
  - name: QDRANT__SERVICE__READ_ONLY_API_KEY
    valueFrom:
      secretKeyRef:
        name: '{{ include "qdrant.fullname" . }}'
        key: readOnlyApiKey

For release tenant, this renders both references as:

secretKeyRef:
  name: tenant-qdrant

Compatibility and scope

• Existing literal valueFrom objects render unchanged.
• The change is limited to values explicitly supplied under env[].valueFrom.
• The chart already evaluates user-provided values with tpl in affinity, topology spread constraints, ServiceMonitor configuration, and other fields, so this follows an existing chart convention.
• It avoids changing the current API-key generation and lookup behavior; users who manage Secrets with External Secrets Operator or another controller can continue using the environment-variable approach.

Validation

I tested the one-line change locally against chart 1.19.0:

helm lint: 1 chart linted, 0 failed
release: tenant
rendered QDRANT__SERVICE__API_KEY secret: tenant-qdrant
rendered QDRANT__SERVICE__READ_ONLY_API_KEY secret: tenant-qdrant

A focused template test using a non-default release name would help prevent regressions.