fix(operator): allow multiple keys of one Secret in spec.secrets

[lightsabit]

Summary

• spec.secrets entries are per-key references — name and key are both required, and the operator's env builder turns each entry into its own secretKeyRef env var — but the list was declared x-kubernetes-list-type: map keyed on [name] alone (MCPServer spec.secrets list-map-keys=[name] makes two keys from one Secret unrepresentable #6686). Two entries sharing a Secret name are therefore treated as duplicate list keys and rejected at admission with duplicate entries for key [name="..."].
• Added key as a second +listMapKey on MCPServerSpec.Secrets and regenerated the CRDs. v1alpha1.MCPServerSpec is v1beta1.MCPServerSpec, so both served versions pick up the new merge keys from the single marker change.
• Widening the key set only relaxes validation: existing objects already have unique names, so nothing changes for them.

Fixes #6686

Type of change

• Bug fix

Test plan

• Unit tests (task test) — via CI on this PR
• E2E tests (task test-e2e) — via CI on this PR (E2E core + operator suites, kind 1.33–1.35)
• Linting (task lint-fix) — via CI on this PR
• Manual testing (describe below)

Manual:

• The identical [name, key] schema change has been running on a live cluster as a Helm post-renderer over the released operator-crds chart since the 0.49.0 release, through 0.50.0 and now 0.51.3. Two MCPServers there — e.g. one that logs in with a username/password pair held in a single Secret — reference 5 and 2 keys of that Secret and reconcile correctly, with real tool calls round-tripping through the gateway.
• The CRDs generated by this branch were verified directly with envtest (suite added in this PR): kube-apiserver loads the CRDs from deploy/charts/operator-crds/files/crds, and an MCPServer referencing two keys of one Secret is admitted through both create and server-side apply on v1beta1 and v1alpha1, with both entries stored. An exact (name, key) duplicate is still rejected. Run locally with envtest 1.31.0 (the version task operator-test-integration pins) and 1.35.0, via the same ginkgo invocation Operator CI uses.
• Falsification check: with the unpatched main CRDs swapped in, the same suite fails exactly as MCPServer spec.secrets list-map-keys=[name] makes two keys from one Secret unrepresentable #6686 describes (duplicate entries for key [name="shared-secret"]), so the tests exercise the original validation failure rather than passing vacuously.

API Compatibility

• This PR does not break the v1beta1 API, OR the api-break-allowed label is applied and the migration guidance is described above.

Touches the v1beta1 surface but is a relaxation only: adding key to the list-map keys accepts every previously valid object and newly accepts same-Secret multi-key lists that were previously rejected. The CRD Schema Compatibility check passes.

Changes

File	Change
cmd/thv-operator/api/v1beta1/mcpserver_types.go	+listMapKey=key on Secrets
deploy/charts/operator-crds/files/crds/toolhive.stacklok.dev_mcpservers.yaml	Regenerated: key added to x-kubernetes-list-map-keys (both served versions)
deploy/charts/operator-crds/templates/toolhive.stacklok.dev_mcpservers.yaml	Same regeneration, templated copy
cmd/thv-operator/test-integration/mcp-server-secrets-admission/secrets_admission_test.go	envtest admission regression suite for #6686

Does this introduce a user-facing change?

Yes — MCPServer objects that reference multiple keys of the same Secret in spec.secrets now pass CRD validation instead of failing with duplicate entries for key [name="..."].

Special notes for reviewers

• The post-renderer soak above patches the released chart CRDs at deploy time; its delta on the secrets field is schema-identical to this PR's generated CRDs (both served versions keyed on name + key).
• Minimal failing manifest and exact server-side dry-run command: posted to MCPServer spec.secrets list-map-keys=[name] makes two keys from one Secret unrepresentable #6686.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 79.28%. Comparing base (61aaf42) to head (21a7f35).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6690      +/-   ##
==========================================
- Coverage   79.34%   79.28%   -0.07%     
==========================================
  Files         802      802              
  Lines       81211    81211              
==========================================
- Hits        64436    64385      -51     
- Misses      16770    16821      +51     
  Partials        5        5              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Sanskarzz]

@lightsabit Thanks for raising the PR.
The (name, key) schema change looks right, and the generated CRDs cover both served versions. Could you add a regression test that applies an MCPServer with two keys from the same Secret through API admission? The existing Go test does not exercise the validation failure in #6686. Please also update the PR body using the repository template: include Fixes #6686, select Bug fix, list the checks you actually ran, and assess API compatibility. Your post-renderer test is useful context; please clarify whether you also tested the CRDs generated by this PR. The issue would benefit from a minimal failing manifest and the exact server-side dry-run command.

[lightsabit]

@Sanskarzz thanks for the review — all four asks are addressed:

• Regression test: added cmd/thv-operator/test-integration/mcp-server-secrets-admission (envtest; runs in Operator CI via task operator-test-integration). It applies an MCPServer referencing two keys of the same Secret through API admission — via both create and server-side apply, on v1beta1 and v1alpha1 — and asserts an exact (name, key) duplicate is still rejected. Verified it reproduces the MCPServer spec.secrets list-map-keys=[name] makes two keys from one Secret unrepresentable #6686 failure when run against the unpatched main CRDs.
• PR body: rewritten with the template — Fixes #6686, Bug fix, the checks that ran, and the API-compat assessment.
• CRDs generated by this PR: yes — the envtest suite installs the CRDs from this branch's deploy/charts/operator-crds/files/crds and exercises the multi-key shape against a real API server (details in the PR body).
• Repro: minimal failing manifest + kubectl apply --server-side --dry-run=server command posted to MCPServer spec.secrets list-map-keys=[name] makes two keys from one Secret unrepresentable #6686.

[Sanskarzz]

LGTM, @JAORMX Please take a final look.

[JAORMX]

lgtm. Thanks @Sanskarzz for the heads up