Add explicit imagePullSecrets field to MCPRegistry and VirtualMCPServer

Summary

MCPRegistry and VirtualMCPServer both spawn workloads from container images, but neither has an explicit imagePullSecrets field. Users who need to pull from a private registry must know to use the raw-JSON spec.podTemplateSpec escape hatch:

spec:
  podTemplateSpec:
    spec:
      imagePullSecrets:
        - name: regcred

This does work today (verified by the integration test at cmd/thv-operator/test-integration/mcp-registry/deployment_update_test.go:63 for MCPRegistry, and by the strategic-merge implementation for VirtualMCPServer), 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.

Proposal

Add an explicit field to both CRDs that mirrors the MCPServer shape, e.g.:

• MCPRegistry.spec.resourceOverrides.deployment.imagePullSecrets
• VirtualMCPServer.spec.resourceOverrides.deployment.imagePullSecrets

The field should be of type []corev1.LocalObjectReference (matching MCPServer's ProxyDeploymentOverrides.ImagePullSecrets) and propagate to:

• the spawned Deployment's PodSpec.ImagePullSecrets, and
• the ServiceAccount the operator creates for that workload.

The existing podTemplateSpec workaround should continue to work (so existing manifests don't break); when both are set, an explicit precedence rule should be documented (suggested: explicit field acts as default, podTemplateSpec wins on overlap, matching the existing podTemplateSpec merge semantics).

Out of scope

This issue is not about fixing broken propagation — both CRDs already work via podTemplateSpec. It's purely about adding a discoverable, consistent API surface.

For genuinely broken propagation in the same area, see #5099 (MCPRemoteProxy) and #5100 (EmbeddingServer).