Drop chart version from PodMonitor/ServiceMonitor selectors

What does this MR do?

Drops the chart label from spec.selector.matchLabels in PodMonitor and ServiceMonitor. The label is retained in metadata.labels — only removed from the selector.

 selector:
   matchLabels:
     app: my-gitlab-runner
-    chart: gitlab-runner-0.88.2
     release: my-gitlab-runner
     heritage: Helm

Why?

gitlab-runner.chart renders as <name>-<version> (e.g. gitlab-runner-0.88.2), so including it in the selector means the monitor only matches pods/services labelled with the exact chart version that rendered it. Every helm upgrade then blackholes scrapes for old replicas still carrying the previous chart-<oldver> label until they roll — and any pod that for whatever reason isn't recreated becomes silently unscraped.

The rest of the chart already avoids this: Deployment.spec.selector is just app, Service.spec.selector is app + release. The monitors were the odd ones out, and version-bound selectors are an anti-pattern Helm explicitly calls out — chart belongs in metadata, not in selectors.

The new selector (app + release + heritage) is a superset of the Deployment's pod selector, uniquely identifies this release's targets, and stays stable across upgrades.

Impact

• PodMonitor/ServiceMonitor spec.selector is mutable, so helm upgrade applies cleanly — no manual delete/recreate.
• Metrics continuity across chart upgrades is preserved.
• No values changes, no API changes, no behaviour change when chart version is held constant.

Verification

helm template with monitors enabled renders:

selector:
  matchLabels:
    app: "test-gitlab-runner"
    release: "test"
    heritage: "Helm"

metadata.labels still contains chart: gitlab-runner-<version> on both monitors. No unit tests reference these resources.

refs gitlab-com/gl-infra/ci-runners#23 (closed)