MCPServer spec.secrets list-map-keys=[name] makes two keys from one Secret unrepresentable

The 0.49.0 CRDs declare spec.secrets as x-kubernetes-list-type: map with x-kubernetes-list-map-keys: [name], but every entry is a per-key reference {name, key, targetEnvName} (name and key both required).

The operator's env builder (cmd/thv-operator/pkg/controllerutil/podtemplatespec_builder.go, WithSecrets) maps each entry to one secretKeyRef env var, so referencing several keys of the SAME Secret is the intended use — but with the merge keys on [name] alone that shape is unrepresentable: any CR listing two entries with the same secret name fails server-side apply/dry-run with duplicate entries for key [name="..."]. Mine (one Secret, five keys) fails exactly that way against the 0.49.0 CRDs; the same manifest was fine against 0.0.106, which had no list-type markers.

A CR-side workaround (splitting one Secret into N single-key Secrets) is ugly, so I patched the CRD's list-map-keys to [name, key] via a post-renderer — everything else about the schema works, and the operator code already treats entries as per-key.

Affects both served versions (v1alpha1 and v1beta1) and is still on main.

Start with cmd/thv-operator/pkg/controllerutil/podtemplatespec_builder.go and the WithSecrets entry point, then inspect the CRD schemas for v1alpha1 and v1beta1. Reproduce the server-side apply or dry-run failure using two entries with the same Secret name and different keys. Done means both keys are representable and the affected CRDs accept the manifest.