fix: drop null-valued labels/annotations keys in metadata tidy

[yxxhero]

Summary

Fixes #1064

helm diff shows a confusing labels-only diff entry like:

  metadata:
    finalizers:
    - externalsecrets.external-secrets.io/externalsecret-cleanup
-   labels:
    name: webhook-token

when one side of the diff renders an empty labels key and the other omits it.

Root cause

Kubernetes treats a null or empty labels/annotations map exactly like an absent key, but charts frequently render the empty key anyway, e.g. via a conditional block:

metadata:
  name: webhook-token
  labels:
{{- with .Values.labels }}
{{ toYaml . | indent 4 }}
{{- end }}

Two gaps left that noise in the diff:

1. manifest.Parse kept the raw text of both sides untouched for the plain (text) diff, so a stored manifest containing a bare labels: (null) or labels: {} produced a meaningless - labels: entry against a new chart revision that omits the key.
2. deleteStatusAndTidyMetadata/pruneNestedMap (live-object tidy used by --three-way-merge and --take-ownership) only handled map-typed values, so a null "labels": null value survived pruning with the same effect.

Fix

1. stripEmptyMetadataKeys drops labels:/annotations: lines from each parsed manifest whenever the parsed value is null or an empty mapping. The removal is line-based so surrounding text keeps its original formatting (# Source comments, key order, indentation); the parsed document is only consulted to confirm the key really carries no content, so keys with entries (including nested spec.template.metadata.labels) are untouched.
2. pruneNestedMap removes the key when its value is null, in addition to the existing removal when the pruned map ends up empty.

Testing

• Unit tests: null labels/annotations keys are removed by the tidy; null/empty/{} labels lines are stripped by Parse while labels with content and nested pod-template labels are kept.
• New CI integration script scripts/repro-issue-1064.sh runs against the kind cluster in CI and covers (plain + three-way-merge):
  • A: chart resource without any labels
  • B: release installed with an explicit managed-by label, diffed against a chart version that dropped it
  • C: chart rendering a bare labels: (null) key vs a version without the block — the exact Bug: helm-diff shows - labels, if resource contains only app.kubernetes.io/managed-by label #1064 symptom (- labels:)
  • D: custom resource (unstructured/CRD path, like the ExternalSecret in the issue) with finalizers and no labels
  • E: flux-style extra labels on the live object
  • F: --take-ownership
  • G: --dry-run=server
  • H: explicit empty labels: {} map — produces - labels: {} without the fix

Signed-off-by: yxxhero aiopsclub@163.com