bug: Stop child shard creation and deletion from rolling unrelated KCP workloads #4440

Describe the bug

With spec.auth.serviceAccount.enabled: true on the RootShard and FrontProxy,
creating or deleting a child Shard rolls the root shard, the front proxy, and all
existing child shards, although their own spec is unchanged.

Observed: the pod templates of existing workloads change when shard membership
changes (service-account key-file args / Secret volume mounts / Secret
resource-version labels <confirm against internal/resources/...>). Deleting the
child restores the old template, so Kubernetes reuses the old ReplicaSet but
creates new pods, causing a second rollout.

Steps To Reproduce

1. Deploy a RootShard and FrontProxy with auth.serviceAccount.enabled: true.
2. Create child Shard A; wait until its API is available.
3. Record pod UIDs of the root shard, front proxy, and Shard A.
4. Create child Shard B. Observe the recorded pods are replaced.
5. Delete Shard B. Observe the pods are replaced again.
6. Poll Shard A's API through the front proxy throughout; observe disruption.

Expected Behaviour

Adding or removing a child shard does not restart unrelated workloads, and
existing shards keep working API access and authentication throughout.

Additional Context

No response