fix(helm): parameterize resource names to enable multi-operator sharding via Helm

[timmy-mathew-ah]

Summary

Parameterize all hardcoded Kubernetes resource names in Helm chart templates using the existing {{ include "camel-k.fullname" . }} helper, enabling installation of multiple Camel-K operators on the same cluster via Helm without resource name collisions in same or different namespaces.

Fixes #6145, #6533

Problem

The official Camel-K documentation describes an operator sharding pattern when you set global:true during helm install where each operator has a unique OPERATOR_ID and only reconciles resources annotated with the matching camel.apache.org/operator.id. However, installing multiple operators via Helm fails because all resource names are hardcoded to camel-k-* regardless of the Helm release name or custom value.

Since ClusterRoles and ClusterRoleBindings are cluster-scoped (shared across all namespaces), the second helm install immediately collides with the first:

helm install camel-k-shard-1 camel-k/camel-k \
  --namespace camel-k-shard-1 \
  --create-namespace \
  --set-string operator.global=true \
  --set operator.operatorId=camel-k-shard-1

helm install camel-k-shard-2 camel-k/camel-k \
  --namespace camel-k-shard-2 \
  --create-namespace \
  --set-string operator.global=true \
  --set operator.operatorId=camel-k-shard-2

# Error: INSTALLATION FAILED: unable to continue with install:
# ClusterRole "camel-k-operator" in namespace "" exists and cannot be
# imported into the current release: invalid ownership metadata;
# annotation validation error: key "meta.helm.sh/release-name" must equal
# "camel-k-shard-2": current value is "camel-k-shard-1"

PR #6191 previously removed several unnecessary cluster-scoped resources but the core problem remained, resource names were still hardcoded and not parameterized by release name.

Backward Compatibility

Fully backward compatible

The camel-k.fullname helper returns camel-k when the release name is camel-k (the standard install). All resource names resolve to their original hardcoded values and the rendered output is identical to the original chart for both global: true and global: false modes.

# Standard install — output identical to before this fix
helm install camel-k camel-k/camel-k --namespace camel-k --create-namespace

Supported Deployment Patterns

Pattern	Before	After
Single operator, global: false	✅	✅
Single operator, global: true	✅	✅
Multiple global operators, separate namespaces	❌ ClusterRole collision	✅
Multiple global operators, same namespace	❌ All resource collisions	✅
Multiple namespaced operators, same namespace	❌ All resource collisions	✅
Mixed global + namespaced operators	❌ ClusterRole collision	✅

---

Usage Examples

Single operator (unchanged behaviour)

helm install camel-k camel-k/camel-k \
  --namespace camel-k \
  --create-namespace

Multiple global operators - separate namespaces

Each operator in its own namespace, watching the entire cluster, only reconciling integrations annotated with its operator.id:

helm install camel-k-shard-1 camel-k/camel-k \
  --namespace camel-k-shard-1 \
  --create-namespace \
  --set-string operator.global=true \
  --set operator.operatorId=camel-k-shard-1

helm install camel-k-shard-2 camel-k/camel-k \
  --namespace camel-k-shard-2 \
  --create-namespace \
  --set-string operator.global=true \
  --set operator.operatorId=camel-k-shard-2

Multiple global operators - same namespace

All operators managed in a single namespace. Enables IntegrationKit sharing across shards (same runtime = reuse of already built kits):

helm install camel-k-shard-1 camel-k/camel-k \
  --namespace camel-k-operators \
  --create-namespace \
  --set-string operator.global=true \
  --set operator.operatorId=camel-k-shard-1

helm install camel-k-shard-2 camel-k/camel-k \
  --namespace camel-k-operators \
  --set-string operator.global=true \
  --set operator.operatorId=camel-k-shard-2

Known Limitation

The builder ServiceAccount name (camel-k-builder) is hardcoded in Go code at pkg/platform/defaults.go:

BuilderServiceAccount = "camel-k-builder"

Builder pods always use this SA name regardless of the Helm release name. This means:

• Helm creates per-release builder SAs (e.g., camel-k-shard-1-builder) for RBAC consistency
• The operator Go code creates and uses camel-k-builder at runtime for actual builder pods

This is pre-existing behaviour, unchanged by this PR.

---