fix(builder): keep explicitly-set false/0 values when merging CR templates

[AndreyZa]

Summary

removeEmpty() pruned every JSON value equal to the zero value of its Go type, so an explicitly-set false or 0 in a CR pod/container template was dropped from the strategic merge patch and never reached the built workload.

The fields at risk are *bool/*int64 with omitempty in the Kubernetes API types: they are marshalled only when the user set them, so pruning them discarded configuration rather than noise. Nulls, empty strings, empty objects and empty lists are still pruned, so unset non-pointer fields keep their previous behaviour.

Concretely, spec.login.securityContext.allowPrivilegeEscalation: false on a LoginSet is stored in the CR but absent from the Deployment, so the login container runs with NoNewPrivs: 0 and a LoginSet cannot satisfy the restricted Pod Security Standard. The chart's own default (loginsetDefaults.login.securityContext.privileged: false) is lost the same way, as are readOnlyRootFilesystem: false, runAsUser: 0 and terminationGracePeriodSeconds: 0. The helper is shared by BuildContainer and BuildPodTemplate, so every builder is affected.

Closes #252.

Checklist

• I have read the
  CONTRIBUTING.md
  and the
  Code of Conduct.
• New or existing tests cover these changes (where applicable).
• Documentation is updated if user-visible behavior changes. (No documentation change: the fix makes the builders honour values the CRD already documents.)

Breaking Changes

None intended. Values that users set explicitly to false/0 now reach the workload; anything left unset is pruned exactly as before. A deployment that relied on an explicit false being silently ignored would change, but that would be the bug itself.

Testing Notes

• internal/utils/structutils/kube_test.go gains a subtest that merges a patch carrying container-level privileged: false / allowPrivilegeEscalation: false and pod-level automountServiceAccountToken: false, terminationGracePeriodSeconds: 0, securityContext.runAsUser: 0. It fails on main and passes with this change. make test is green (50 packages).

• Verified on a cluster (Kubernetes v1.35.8 / k0s, charts slurm-operator-1.2.1 / slurm-1.2.1, one LoginSet declaring all five fields; only the operator image swapped):

  Before (ghcr.io/slinkyproject/slurm-operator:1.2.1):

  container.securityContext: {"capabilities":{"add":[...],"drop":["ALL"]}}
  pod.terminationGracePeriodSeconds: 30
  pod.securityContext: {}
  

  After (this branch):

  container.securityContext: {"allowPrivilegeEscalation":false,"capabilities":{"add":[...],"drop":["ALL"]},"privileged":false,"readOnlyRootFilesystem":false}
  pod.terminationGracePeriodSeconds: 0
  pod.securityContext: {"runAsUser":0}
  

  and in the login pod: NoNewPrivs: 1.

Additional Context

Found while trying to run a LoginSet under the restricted Pod Security Standard.

[vivian-hafener]

Please update this PR to use the provided Pull Request Template: https://github.com/SlinkyProject/slurm-operator/blob/main/.github/pull_request_template.md