fix(falcon-sensor): exclude release namespace from pullSecrets.allNamespaces loop

[venu1202]

Summary

Fixes #533 — container.image.pullSecrets.allNamespaces renders two Secret manifests with the same name and namespace: the unconditional base Secret (always placed in the release's namespace), and a duplicate of it via the allNamespaces lookup loop, which enumerates every namespace on the cluster with no exclusion for the release's own namespace.

Root cause

{{- range $index, $ns := (lookup "v1" "Namespace" "" "").items -}}
  {{ $myns = append $myns $ns.metadata.name }}
{{- end }}

lookup "v1" "Namespace" "" "" returns every namespace, including the one this chart is installed into — which already gets a Secret from the unconditional block earlier in this same template. That produces two manifest entries with an identical {kind, namespace, name} key.

Impact

Helm's pkg/kube/client.go processes the second occurrence of that key by checking whether it's present in original (the previous release revision's tracked manifest). On the first upgrade that ever introduces this configuration, it isn't — so Helm v3 SDK clients (anything built on helm.sh/helm/v3, e.g. terraform-provider-helm) fail with:

UPGRADE FAILED: no Secret with the name "<release>-pull-secret" found

If atomic: true is set, this rolls back to the pre-secret state every time, so every retry hits the identical first-time-introduction failure — the release can never progress past it with this exact config. (Helm v4 CLI instead logs a warning and adopts the resource using cluster state as a baseline, which is why this wasn't caught in ad-hoc CLI testing.)

Fix

Exclude the release's own namespace from the allNamespaces loop:

{{- if .Values.container.image.pullSecrets.allNamespaces }}
{{- $myns = list -}}
{{- range $index, $ns := (lookup "v1" "Namespace" "" "").items -}}
  {{- if ne $ns.metadata.name (include "falcon-sensor.namespace" .) }}
  {{ $myns = append $myns $ns.metadata.name }}
  {{- end }}
{{- end }}
{{- end }}

include "falcon-sensor.namespace" . resolves to wherever the release is actually installed (default falcon-system, or a custom namespace if overridden), so this excludes exactly the namespace already covered by the unconditional base Secret — no other namespace is affected.

Testing

• helm template before/after confirms the duplicate falcon-system entry is gone, while all other requested namespaces still receive the Secret as before.
• Verified against the failure mode in container.image.pullSecrets.allNamespaces renders a duplicate Secret in the release's own namespace, breaking Helm v3-SDK clients on first introduction #533: a release introducing pullSecrets.enable: true + allNamespaces: true for the first time via a Helm v3 SDK client, with atomic: true, now upgrades successfully instead of failing/rolling back.