additionalVolumeClaimTemplates: is "fixed at creation" a permanent constraint, or could additions be allowed?

### Company or project name

_No response_

### Use case

Two situations, both on clusters that already exist and hold data:

1. Growing capacity. Adding a disk is the natural way to extend a cluster that's filling up. Today that's only available to clusters whose authors anticipated it at creation time; everyone else has to recreate.

2. Per-tenant storage isolation. We need a dedicated volume encrypted with a specific customer's managed KMS key, holding exactly one tenant's table and nothing else. This requirement arrives well after the cluster is built — it comes from a contract, not from capacity planning — and the key doesn't exist until the customer creates it. Recreating a multi-terabyte production cluster to attach it isn't practical.

### Describe the solution you'd like

Allow additions to additionalVolumeClaimTemplates after cluster creation.

Note the restriction is currently enforced in two places, so the webhook alone isn't the whole change:

```
// internal/webhook/v1alpha1/common.go:125 — rejects the spec change
if len(oldTemplates) != len(newTemplates) {
return errors.New("additionalVolumeClaimTemplates cannot be added or removed after cluster creation")
}
```

```
// internal/controller/resourcemanager.go:269 — discards it on reconcile
statefulSet.Spec.VolumeClaimTemplates = input.Existing.STS.Spec.VolumeClaimTemplates
```

One mechanism that avoids the immutability problem entirely: volumeClaimTemplates are only used for provisioning, and a StatefulSet uses a PVC that already exists under the name it expects. So the operator can create the PVC directly per replica and reference it from the pod template — which is mutable — leaving volumeClaimTemplates untouched.

### Describe alternatives you've considered

- Declare spare disks at creation time. Doesn't fit either use case: you'd pay for idle volumes indefinitely, and you cannot pre-declare a StorageClass for a customer KMS key that doesn't exist yet.
- Declare the disk via settings.extraConfig without a claim. This appears to work and silently doesn't. With no PVC, the disk's path is just a directory on the main data volume — ClickHouse registers the disk, system.disks shows it, a storage policy over it works, and parts report landing on it. For an encryption-isolation requirement that's the worst failure mode available: every signal says success while the data sits on the wrong volume under the wrong key. The tell is total_space matching the main volume.
- Recreate the ClickHouseCluster CR against the existing PVCs. Plausible, but it means deliberate downtime on a production cluster and depends on adoption behaving exactly as hoped.
- Recreate the StatefulSet with orphaned PVCs. Also viable and possibly what you'd prefer — more invasive, but keeps volumeClaimTemplates authoritative.
- A downstream patch. What we do today. We'd rather not carry it, which is why we're asking here.

### Additional context

_No response_

Start with internal/webhook/v1alpha1/common.go around line 125 and internal/controller/resourcemanager.go around line 269 to trace validation and reconciliation of additionalVolumeClaimTemplates. Then inspect how the operator provisions and references StatefulSet PVCs for existing clusters. Done means additions can be applied to an existing data-bearing cluster without being rejected or discarded, while preserving the intended PVC and StatefulSet behavior.

Written by the indexing model from the issue text.