fix: correct CRD type mismatches and add omitempty to status fields

[sharanrajt]

Summary

• Go's int is platform-dependent (32- or 64-bit), but Kubernetes CRD integer fields should use explicitly sized types (int32/int64). Several CRD structs (VirtualMCPServerStatus.BackendCount, MCPRegistryDatabaseConfig.Port/MaxOpenConns/MaxIdleConns, SyncStatus.AttemptCount/ServerCount) used bare int, producing an imprecise OpenAPI schema and causing testify type-mismatch failures.
• MCPGroupStatus.Servers and MCPGroupStatus.ServerCount lacked omitempty on their JSON tags, causing zero-value fields to always appear in serialised status payloads.

What changed:

• Changed BackendCount, Port, MaxOpenConns, MaxIdleConns, AttemptCount, and ServerCount from int to int32 in CRD types
• Updated GetDatabasePort() return type to int32
• Added inline bounds check (capped at math.MaxInt32) in k8s_reporter.go before casting to int32
• Added explicit int() / int32() casts at all call sites to satisfy the new types
• Regenerated CRD manifests (format: int32 added to affected fields)
• Updated unit, integration, and E2E tests to use int32 literals and BeEquivalentTo matcher
• Added omitempty to Servers and ServerCount JSON tags in MCPGroupStatus

Fixes #4544
Fixes #4537

Type of change

• Bug fix
• New feature
• Refactoring (no behavior change)
• Dependency update
• Documentation
• Other (describe):

Test plan

• Unit tests (task test)
• E2E tests (task test-e2e)
• Linting (task lint-fix)
• Manual testing (describe below)

Changes

File	Change
cmd/thv-operator/api/v1alpha1/mcpgroup_types.go	Add omitempty to Servers and ServerCount JSON tags
cmd/thv-operator/api/v1alpha1/mcpregistry_types.go	Change Port, MaxOpenConns, MaxIdleConns, AttemptCount, ServerCount from int to int32; update GetDatabasePort() return type
cmd/thv-operator/api/v1alpha1/virtualmcpserver_types.go	Change BackendCount from int to int32
cmd/thv-operator/pkg/registryapi/config/config.go	Add int() casts when assigning int32 CRD fields to internal config
cmd/thv-operator/pkg/registryapi/pgpass_test.go	Cast port to int32 in test helper
cmd/thv-operator/pkg/virtualmcpserverstatus/collector.go	Cast readyCount to int32 when assigning BackendCount
cmd/thv-operator/test-integration/mcp-registry/status_helpers.go	Cast SyncStatus.ServerCount to int for Gomega comparison
deploy/charts/operator-crds/files/crds/toolhive.stacklok.dev_mcpregistries.yaml	Add format: int32 to port, maxOpenConns, maxIdleConns, attemptCount, serverCount
deploy/charts/operator-crds/files/crds/toolhive.stacklok.dev_virtualmcpservers.yaml	Add format: int32 to backendCount
deploy/charts/operator-crds/templates/toolhive.stacklok.dev_mcpregistries.yaml	Same CRD template regeneration
deploy/charts/operator-crds/templates/toolhive.stacklok.dev_virtualmcpservers.yaml	Same CRD template regeneration
pkg/vmcp/status/k8s_reporter.go	Add math import; inline bounds check capping at MaxInt32 before int32 cast
pkg/vmcp/status/k8s_reporter_test.go	Change backendCount field to int32; update loop variable, assertions, and Len calls
test/e2e/thv-operator/virtualmcp/virtualmcp_yardstick_base_test.go	Use BeEquivalentTo(2) instead of Equal(2) for BackendCount

Does this introduce a user-facing change?

No. The serialised status output becomes cleaner (zero-value MCPGroupStatus fields now omitted), and the CRD OpenAPI schema is more precise (format: int32), but API semantics are unchanged.

Special notes for reviewers

• nolint:gosec comments on int32() casts are guarded by an explicit math.MaxInt32 bounds check in k8s_reporter.go, or are inherently safe because the values are small counts (backend count, connection pool sizes).
• The E2E test switches from Equal(2) to BeEquivalentTo(2) to avoid Gomega's strict type matching between int and int32.

[jerm-dro]

nitpick: The PR description lists several changes that aren't in the diff — switching PgpassSecretRef to SecretKeyReference, adding omitempty to User/Password, and a safeIntToInt64 helper. The actual code does an inline bounds check instead of a helper, and the other two changes don't appear at all. Could you trim the description to match what's actually here? Makes it easier for reviewers (and future git-log readers) to understand the scope.

The actual changes fully address both #4544 and #4537 — looks good.

[sharanrajt]

Thanks for the review, I have updated the PR description to match the actual diff. Let me know if anything else needs adjusting!