fix(client): release-scope resource-monitor names so multiple releases can coexist (v1.2.0)

[saadqbal]

Summary

Two client releases on the same cluster could not both deploy the resource-monitor DaemonSet — several resources templated into the shared `tracebloc-node-agents` namespace used the literal name `tracebloc-resource-monitor` rather than a release-scoped name. The second `helm install` failed with:

```
Error: ServiceAccount "tracebloc-resource-monitor" in namespace "tracebloc-node-agents"
exists and cannot be imported into the current release: invalid ownership metadata;
annotation validation error: key "meta.helm.sh/release-name" must equal "internal-prod":
current value is "stg"; ...
```

Surfaced during the 2026-04-27 `internal-prod` migration on `tracebloc-templates-prod`; the workaround was `resourceMonitor: false` on the second release, which means prod customers currently lose their per-`CLIENT_ID` metric stream until this lands.

Changes

• New helper `tracebloc.resourceMonitorName` → `<Release.Name>-resource-monitor`, alongside the existing per-release name helpers (`secretName`, `serviceAccountName`).
• DaemonSet `metadata.name`, `spec.selector.matchLabels.app`, pod label `app=`, and `spec.template.spec.serviceAccountName` all now go through the helper. Selector + pod label move together: DaemonSet selectors are namespace-scoped, so two DaemonSets in `tracebloc-node-agents` both selecting `app: tracebloc-resource-monitor` would each grab the other's pods — worse than the surface bug.
• ServiceAccount `metadata.name` goes through the helper. `ClusterRole`, `ClusterRoleBinding`, `Role`, `RoleBinding` `metadata.name` were already release-scoped (`tracebloc-resource-monitor-`) and stay as-is to avoid an unnecessary rename. Only the subject names in (Cluster)RoleBinding change to point at the new SA.
• Mirrored secrets in `tracebloc-node-agents`: secret names were already release-scoped via `tracebloc.secretName` / `tracebloc.registrySecretName` (no collision). Their `app` label was the literal value — harmless on uniquely-named resources, but inconsistent. Updated for consistency.
• Chart bumped 1.1.0 → 1.2.0. Per-release naming of cluster-singleton resources is a behaviour change, so a minor bump signals operators should review.

Verification

```
=== stg === === internal-prod ===
ServiceAccount stg-resource-monitor ServiceAccount internal-prod-resource-monitor
DaemonSet stg-resource-monitor DaemonSet internal-prod-resource-monitor
ClusterRoleBinding tracebloc-resource-monitor-stg ClusterRoleBinding tracebloc-resource-monitor-internal-prod
subject: stg-resource-monitor subject: internal-prod-resource-monitor
```

Both releases would now coexist on one cluster.

Test plan

• `helm lint` clean
• `helm unittest client` — 98/98 (was 93). New cases:
  • DaemonSet name + selector + serviceAccountName release-scoped
  • ServiceAccount name release-scoped
  • ClusterRoleBinding subject points at the release-scoped SA
  • A different release name produces non-colliding DaemonSet + SA names
• `helm template` rendered side-by-side for two release names; resource-monitor names diverge per release.
• In stg: `helm upgrade` from current 1.1.0 install. Watch the resource-monitor DaemonSet pods cycle (delete-then-create) on each node, then confirm a fresh DaemonSet `stg-resource-monitor` is running. ~30-60s metrics gap per node is expected.
• Then in prod: `helm upgrade internal-prod ./client` with `resourceMonitor: true` (which had to be `false` on the 2026-04-27 install due to this bug). Confirm `internal-prod-resource-monitor` DaemonSet comes up alongside stg's, both healthy, no name collisions in `tracebloc-node-agents`.

Upgrade path from 1.1.0

DaemonSet and ServiceAccount rename triggers a Helm three-way merge: the names diverge in the stored manifest, so Helm DELETEs the old `tracebloc-resource-monitor` resource and CREATEs the new release-scoped one. ~30-60s gap on each node where resource metrics are not collected. DaemonSet selector is immutable, but the rename means Helm goes through delete+create rather than patching the immutable field, so the upgrade is automatic. No manual orphan cleanup needed.

Out of scope

• Migrating away from the workaround on `internal-prod` (flipping `resourceMonitor: false` → `true` after this lands) is a separate operational step — it follows the same `helm upgrade` path documented above.
• Documentation update for `docs/MIGRATIONS.md` Option B (covered in the companion PR).

---

Note

Medium Risk
Renames resource-monitor DaemonSet/ServiceAccount and selector labels in a shared namespace, which will cause delete+create on upgrade and could briefly interrupt metrics collection if not coordinated.

Overview
Enables multiple client Helm releases to coexist on the same cluster by release-scoping all shared-namespace resource-monitor identities (DaemonSet name, ServiceAccount name, selector/pod app labels, and RBAC binding subjects) via a new tracebloc.resourceMonitorName helper.

Updates mirrored secrets/registry-secret app labels for consistency, expands Helm unit tests to assert non-colliding names across releases, and bumps the chart/app version to 1.2.0.

^{Reviewed by Cursor Bugbot for commit db988eb. Bugbot is set up for automated code reviews on this repo. Configure here.}