Batch MCPServer status updates to reduce API calls per reconciliation

[ChrisJBurns]

Summary

The MCPServer controller calls r.Status().Update() from many independent validation helpers, resulting in 6+ distinct status update API calls on a single happy-path reconcile. This causes unnecessary API server load, conflict errors from consecutive racing updates, and wasted work when later updates overwrite earlier ones.

Severity: MUST FIX
Area: Controller Logic
Breaking: No

Location

• cmd/thv-operator/controllers/mcpserver_controller.go

Problem

The controller makes separate r.Status().Update() calls from many independent helpers:

• validateGroupRef (line 577)
• updateCABundleStatus (line 674)
• validateAndUpdatePodTemplateStatus (lines 737, 756)
• setImageValidationCondition + update (lines 267, 279, 293, 304)
• handleToolConfig (line 952)
• Multiple others in status reconciliation paths

35 total call sites exist; 6+ distinct on the happy path. On error paths, even more.

Impact

• API server load: 6-12 status update calls per reconcile instead of 1
• Conflict errors when consecutive updates race
• Wasted work when a later update overwrites an earlier one

Recommended Fix

Adopt the StatusManager/StatusCollector pattern already used by VirtualMCPServer and MCPRegistry:

1. Collect all condition/status mutations during reconciliation
2. Apply them in a single batch at the end
3. Remove independent Status().Update() calls from validation helpers