Add explicit imagePullSecrets field to MCPRegistry

[JAORMX]

Summary

MCPRegistry workloads previously had no first-class image pull secrets field — users had to use the raw-JSON spec.podTemplateSpec escape hatch. That works (the existing integration test at cmd/thv-operator/test-integration/mcp-registry/deployment_update_test.go:63 proves it) but it has two drawbacks:

1. Discoverability — a user reading the CRD schema sees no field for image pull secrets and won't know the workaround exists.
2. Inconsistency — MCPServer has a first-class field at spec.resourceOverrides.proxyDeployment.imagePullSecrets. Anyone managing both kinds of resources has to remember the API differs.

This PR adds spec.imagePullSecrets to MCPRegistry. The field is []corev1.LocalObjectReference and propagates to:

• the registry-api Deployment's PodSpec.ImagePullSecrets
• the operator-managed ServiceAccount the registry API runs as

Placement choice. I chose spec.imagePullSecrets (flat, top-level on the spec) rather than introducing a spec.resourceOverrides.deployment.imagePullSecrets struct. MCPRegistry has no ResourceOverrides today, and adding one with a single field would be speculative scaffolding. If/when other override fields land, imagePullSecrets can be moved or kept as a top-level alias — but adding a struct now without a second field to justify it is unnecessary.

Precedence with podTemplateSpec. When both spec.imagePullSecrets and spec.podTemplateSpec.spec.imagePullSecrets are set:

• spec.imagePullSecrets is applied first as a controller-generated default.
• spec.podTemplateSpec.spec.imagePullSecrets is the user override and wins on overlap (the list is treated atomically — user's list replaces the default entirely on the Deployment).
• The ServiceAccount is always populated from spec.imagePullSecrets; podTemplateSpec has no notion of a ServiceAccount.

This matches the existing podTemplateSpec merge semantics in MergePodTemplateSpecs and is documented in the field's Go doc comment. The legacy podTemplateSpec workaround keeps working unchanged.

Part of #5101

Type of change

• New feature

Test plan

• Unit tests (task test) — operator unit tests pass; the new TestBuildRegistryAPIDeployment_ImagePullSecrets covers explicit field, empty, podTemplateSpec override, podTemplateSpec without imagePullSecrets, and legacy podTemplateSpec-only behaviour. TestEnsureRBACResources_ImagePullSecrets verifies the ServiceAccount picks up the explicit field.
• Linting (task lint-fix)
• Manual testing — generated CRD YAML inspected (deploy/charts/operator-crds/files/crds/toolhive.stacklok.dev_mcpregistries.yaml) shows the new imagePullSecrets array property and the legacy podTemplateSpec field is unchanged.

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.

This adds a new optional field. Existing CRs continue to work; no migration required.

Does this introduce a user-facing change?

Yes. Users can now set spec.imagePullSecrets directly on MCPRegistry:

apiVersion: toolhive.stacklok.dev/v1beta1
kind: MCPRegistry
metadata:
  name: my-registry
spec:
  configYAML: |
    sources:
      - name: default
        format: toolhive
  imagePullSecrets:
    - name: regcred

The previous spec.podTemplateSpec workaround keeps working.

Special notes for reviewers

VirtualMCPServer has the same gap (tracked by #5101) but is being landed as a separate follow-up PR to keep each diff small and reviewable. The two CRDs do not share the deployment-build code path so the changes don't combine cleanly.

Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 67.03%. Comparing base (5c54e54) to head (a377203).
⚠️ Report is 5 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #5106      +/-   ##
==========================================
+ Coverage   66.92%   67.03%   +0.11%     
==========================================
  Files         595      595              
  Lines       60086    60009      -77     
==========================================
+ Hits        40213    40230      +17     
+ Misses      16804    16725      -79     
+ Partials     3069     3054      -15     

☔ View full report in Codecov by Sentry.
📢 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.

[yrobla]

Review: Add spec.imagePullSecrets to MCPRegistrySpec

Clean, well-structured feature — the CRD field, RBAC wiring, and deployment propagation are all correct. Main concerns are a dead dedup path in WithImagePullSecrets, a subtle SA/Deployment behavioral split that users may not expect, and missing integration test coverage for the new field.

---

Summary of findings:

• [warning] WithImagePullSecrets deduplication logic is dead code — defaultSpec always starts empty, so the existing map never has anything to deduplicate
• [warning] No integration test exercises the new spec.imagePullSecrets field — existing integration tests only cover the podTemplateSpec path
• [warning] SA/Deployment split-brain: using only spec.podTemplateSpec.spec.imagePullSecrets (the old way) populates the Deployment but leaves the SA without credentials; the docs mention this but the risk is subtle
• [nit] MergePodTemplateSpecs docstring says "All other PodSpec fields: User values preserved as-is" — now stale since imagePullSecrets has explicit merge logic
• [nit] WithImagePullSecrets function comment is misleading about what it does