VirtualMCPServer: track OIDCConfigHash through statusManager instead of direct status update

[ChrisJBurns]

Summary

In VirtualMCPServerReconciler.handleOIDCConfig, the OIDCConfigHash field is written directly via r.Status().Update(ctx, vmcp), while all other status fields in the VirtualMCPServer reconciler are buffered through the statusManager and flushed in a single batched applyStatusUpdates call.

This creates a mixed-write pattern: the direct update succeeds with one ResourceVersion, then the batched flush re-fetches and writes again. In practice this works because applyStatusUpdates re-fetches before writing, but a version conflict between the two writes would cause the hash update to be lost (recovered on requeue, but adds an unnecessary round-trip).

Ref: #4493 (comment)

Current behavior

// In handleOIDCConfig — direct write
vmcp.Status.OIDCConfigHash = oidcConfig.Status.ConfigHash
if err := r.Status().Update(ctx, vmcp); err != nil {
    return fmt.Errorf("failed to update MCPOIDCConfig hash in status: %w", err)
}

Desired behavior

Track OIDCConfigHash through the StatusManager like all other status fields. This requires adding a SetOIDCConfigHash(hash string) method to the StatusManager interface and its implementation in the StatusCollector.

Context

The MCPServer controller uses the same direct-update pattern for OIDCConfigHash, but MCPServer doesn't use a statusManager — it writes status directly throughout. The inconsistency is specific to VirtualMCPServer which adopted statusManager for batched updates.

[ChrisJBurns]

Proposed Fix

Three independent reviews (Kubernetes operator expert, Go code writer, code reviewer) converged on the same implementation. All rated the risk as low with no blockers.

Approach

Add SetOIDCConfigHash(hash string) to the StatusManager interface and remove both direct r.Status().Update(ctx, vmcp) calls from handleOIDCConfig. Empty string = clear (matching SetURL/SetMessage semantics).

Changes (~42 lines across 4 source files + mock regen)

File	Change
`types.go`	Add `SetOIDCConfigHash(hash string)` to the `StatusManager` interface, grouped with other scalar setters
`collector.go`	Add `oidcConfigHash *string` field, setter (`&hash` + `hasChanges = true`), and `if s.oidcConfigHash != nil` block in `UpdateStatus`. Update debug log.
`virtualmcpserver_controller.go`	Replace direct `r.Status().Update(ctx, vmcp)` at lines 2742 and 2812 with `statusManager.SetOIDCConfigHash(...)`
`collector_test.go`	Two new tests (set + clear) plus update existing `TestStatusCollector_BatchedUpdates`
`mocks/mock_collector.go`	Regenerate via `task gen`

Controller changes (before → after)

Clear hash (OIDCConfigRef is nil):

// Before
if vmcp.Status.OIDCConfigHash != "" {
    vmcp.Status.OIDCConfigHash = ""
    if err := r.Status().Update(ctx, vmcp); err != nil {
        return fmt.Errorf("failed to clear MCPOIDCConfig hash from status: %w", err)
    }
}

// After
if vmcp.Status.OIDCConfigHash != "" {
    statusManager.SetOIDCConfigHash("")
}

Set hash (config changed):

// Before
vmcp.Status.OIDCConfigHash = oidcConfig.Status.ConfigHash
if err := r.Status().Update(ctx, vmcp); err != nil {
    return fmt.Errorf("failed to update MCPOIDCConfig hash in status: %w", err)
}

// After
statusManager.SetOIDCConfigHash(oidcConfig.Status.ConfigHash)

Why this is safe

1. No downstream reader: OIDCConfigHash is only read at the start of the next reconciliation. No code after handleOIDCConfig in the same loop reads it.
2. Error paths are correct: When handleOIDCConfig errors (config not found/not ready), SetOIDCConfigHash is never called, so the collector leaves the field untouched — matching current behavior.
3. Cross-resource write unaffected: updateOIDCConfigReferencingWorkloads writes to the MCPOIDCConfig resource, not VirtualMCPServer. Not part of this change.
4. Zero existing test breakage: No VirtualMCPServer unit test exercises handleOIDCConfig. Mock regenerates automatically via task gen.

Bonus: eliminates a latent bug

The current direct writes use the original vmcp object (fetched at the top of Reconcile). If runValidations already called applyStatusUpdates (which re-fetches latest), the original vmcp's resourceVersion is stale. The direct write can produce spurious 409 Conflict errors. Routing through the StatusManager eliminates this because applyStatusUpdates always re-fetches before writing.

Design decisions

• string not *string in the public API — matches SetURL(url string) and SetMessage(message string). The pointer is internal to the collector only.
• One method, not generic — type-safe setter consistent with all 14 existing interface methods. A generic SetStatusField(field string, value interface{}) would lose compile-time safety.
• No separate ClearOIDCConfigHash() — empty string is the zero value, omitempty JSON tag makes it serialize to absence. No other field has a separate clear method.
• 15 methods on the interface is acceptable — 7 of 15 are thin condition wrappers. Restructuring not warranted at this size.

Follow-up suggestions (not blockers)

• Add unit tests for VirtualMCPServerReconciler.handleOIDCConfig (currently has zero unit test coverage — MCPServer has TestMCPServerReconciler_handleOIDCConfig but VirtualMCPServer does not).