[FEATURE] Settings change and removal mechanism #3663

Defines how workloads roll when a settings object they consume changes, and how disabled components are removed, without ate-setup and without renaming in-cluster objects.

Tracks the "Settings change and removal mechanism" contract of the Extensible Install Roadmap.

Owner: kustomize release workstream (#3169). Consumers: Helm workstream (#3170), GKE workstream (ai-on-gke/substrate-gke#70).

Current behaviour (upstream/main at 0b635b80), all imperative in ate-setup:

• env-hash annotation on ate-api-server (cmd/ate-setup/internal/steps/apienv.go);
• rollout restarts after OpenTelemetry, egress and CSI changes (steps/overlay.go, steps/csi.go);
• deleting the credential provider when it is disabled (steps/credprovider.go).

Specification (Proposed).

• Restarts. Workloads roll when a consumed settings object changes, without renaming the object.
  • Helm: checksum/<object> pod-template annotations computed from rendered values.
  • kustomize: a render-time checksum annotation, or components that reload their configuration on change. Decide which.
  • Hash-suffixed generator names are rejected: they rename objects in existing clusters and break scripts and code that read them by name.
• Removal. Helm deletes objects it stops rendering. kustomize users run a documented kubectl delete per optional component, or use their GitOps tool's prune. kubectl ApplySet pruning is an option once its maturity is confirmed.

Stability. Provisional until the mechanism is chosen. No consumer depends on object names other than those in #3172.

Enforcement. CI changes the database connection string and the OpenTelemetry endpoint through each install path and asserts that exactly the consuming workloads roll.

Decision needed: restart mechanism that keeps object names stable; pruning on the kubectl path.

Parent Issue: #3160