Batch MCPServer status updates to reduce API calls per reconciliation

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

Start in cmd/thv-operator/controllers/mcpserver_controller.go and compare the StatusManager/StatusCollector pattern already used by VirtualMCPServer and MCPRegistry. Trace the listed validation and status reconciliation helpers, then verify that their mutations are collected and applied in one batch instead of independent Status().Update() calls.