Fix deployment selector labels to use correct Kubernetes recommended label semantics

[linkvt]

Problem

The current (e.g. v0.12.1) release manifests use selector.matchLabels with incorrect label semantics inherited from the kustomize config:

http-add-on/config/default/kustomization.yaml

Lines 11 to 16 in de1a09f

	- includeSelectors: true
	includeTemplates: true
	pairs:
	app.kubernetes.io/name: http
	app.kubernetes.io/component: add-on
	app.kubernetes.io/part-of: keda

Example:

selector:
  matchLabels:
    app.kubernetes.io/component: add-on        # same for all components
    app.kubernetes.io/instance: interceptor     # misused as component differentiator
    app.kubernetes.io/name: http
    app.kubernetes.io/part-of: keda

Issues:

• instance is misused - per the Kubernetes recommended labels spec, instance is meant to differentiate installations of the same application (e.g. mysql-prod vs mysql-staging), not components within an application. component should serve that role.
• component: add-on is the same for all three deployments, providing no differentiation. It should be component: interceptor, component: operator, component: external-scaler.

Desired state

selector:
  matchLabels:
    app.kubernetes.io/name: http-add-on
    app.kubernetes.io/component: interceptor    # or operator, external-scaler

Why this is a breaking change

spec.selector on apps/v1 Deployments is immutable. Changing it requires deleting and recreating the deployments, which causes downtime.

Proposed approach

Include this fix in a major version release where breaking changes are expected. Document the required kubectl delete deployment + kubectl apply upgrade step in the release notes.