Propagate protectedResourceAllowPrivateIP through OIDC resolver and converter

[ChrisJBurns]

Summary

The protectedResourceAllowPrivateIP CRD field was defined on both MCPServer and VirtualMCPServer but never actually propagated through the OIDC resolver, making the field a no-op. Additionally, the vmcpconfig converter incorrectly mapped it from jwksAllowPrivateIP, meaning the two fields could not be controlled independently.

Fixes bugs 2 and 3 from #3142 (Bug 1 was fixed separately via #4250).
The MCPServer/MCPRemoteProxy runner path remains out of scope — tracked in #4787.

Medium level

• Add ProtectedResourceAllowPrivateIP field to the internal oidc.OIDCConfig struct so it can carry the value from CRD types through to consumers
• Propagate the field through all three user-facing resolve paths: inline, shared inline (MCPOIDCConfig), and ConfigMap
• Fix the vmcpconfig converter to map ProtectedResourceAllowPrivateIP from the correct source field (was incorrectly using JWKSAllowPrivateIP)
• Add the missing JwksAllowPrivateIP mapping in the converter so the auth factory's OR logic (ProtectedResourceAllowPrivateIP || JwksAllowPrivateIP) works correctly
• Add missing JWKSURL and IntrospectionURL mappings in mapResolvedOIDCToVmcpConfigFromRef (pre-existing gap fixed opportunistically)
• Document runtime OR behavior on both CRD fields

Low level

File	Change
cmd/thv-operator/pkg/oidc/resolver.go	Add ProtectedResourceAllowPrivateIP to OIDCConfig struct; propagate in resolveInlineConfig, resolveFromInlineSharedConfig, resolveConfigMapConfig; extract configMapBoolTrue constant
cmd/thv-operator/pkg/vmcpconfig/converter.go	Fix mapResolvedOIDCToVmcpConfig and mapResolvedOIDCToVmcpConfigFromRef to use correct source field; add missing JwksAllowPrivateIP, JWKSURL, IntrospectionURL mappings
cmd/thv-operator/api/v1alpha1/mcpoidcconfig_types.go	Document runtime OR behavior on private IP fields
cmd/thv-operator/api/v1alpha1/mcpserver_types.go	Document runtime OR behavior on private IP fields
cmd/thv-operator/pkg/oidc/resolver_test.go	Update "all fields" tests; add independent propagation test cases for inline and ConfigMap
cmd/thv-operator/pkg/oidc/resolver_configref_test.go	Add shared inline config propagation test
cmd/thv-operator/pkg/vmcpconfig/converter_test.go	Update "maps all fields" test; add independent field mapping test

Type of change

• Bug fix
• New feature
• Breaking change
• Refactoring
• Documentation
• Other

Does this introduce a user-facing change?

Setting protectedResourceAllowPrivateIP: true on VirtualMCPServer OIDC config now works as documented. Previously the field was silently ignored.

Note: The field remains a no-op for MCPServer and MCPRemoteProxy — those resource types use a different runner path that only supports jwksAllowPrivateIP. This is tracked in #4787.

Behavioral note: Setting jwksAllowPrivateIP: true previously had the unintended side effect of also enabling private IPs for the protected resource endpoint. After this fix, users who need both must set both fields explicitly.

Test plan

• task lint-fix passes (0 issues on affected packages)
• task test passes on cmd/thv-operator/pkg/oidc/... and cmd/thv-operator/pkg/vmcpconfig/...
• task build passes for cmd/thv-operator/...
• New unit tests: independent propagation (resolver inline, ConfigMap, shared inline), independent field mapping (converter)
• Existing tests updated to cover both fields

Special notes for reviewers

• The Kubernetes and ServiceAccount resolve paths intentionally do NOT propagate ProtectedResourceAllowPrivateIP — those paths auto-configure for cluster-internal OIDC where JWKSAllowPrivateIP is the relevant setting.
• MCPServer/MCPRemoteProxy runner path gap tracked in protectedResourceAllowPrivateIP not propagated through MCPServer/MCPRemoteProxy runner path #4787.

Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 88.23529% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.92%. Comparing base (6a79259) to head (77ac79c).
⚠️ Report is 8 commits behind head on main.

Files with missing lines	Patch %	Lines
cmd/thv-operator/pkg/vmcpconfig/converter.go	33.33%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4784      +/-   ##
==========================================
- Coverage   68.94%   68.92%   -0.03%     
==========================================
  Files         517      517              
  Lines       54741    54749       +8     
==========================================
- Hits        37742    37735       -7     
- Misses      14095    14107      +12     
- Partials     2904     2907       +3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ChrisJBurns]

Multi-Agent Consensus Review

Agents consulted: kubernetes-expert, go-security-reviewer, code-reviewer, toolhive-expert
Recommendation: ✅ APPROVE

Consensus Summary

#	Finding	Consensus	Severity	Action
1	MCPServer/MCPRemoteProxy paths drop ProtectedResourceAllowPrivateIP	8/10	HIGH	Comment (pre-existing)
2	Downstream factory ORs both fields into single AllowPrivateIP	7/10	MEDIUM	Comment (pre-existing)
3	Missing ConfigMap independence test	7/10	LOW	Suggest

Overall

This is a clean, well-scoped bug fix. The core change -- adding ProtectedResourceAllowPrivateIP to the resolver's OIDCConfig struct, propagating it through all three resolution paths (inline, shared inline, ConfigMap), and fixing the converter mapping -- is correct and addresses both bugs from #3142.

All three findings that survived consensus scoring are either pre-existing issues (F1, F2) or a minor test gap (F3). No agent identified any issues introduced by this PR. The test suite includes independence assertions that verify the two fields can be controlled separately, which directly guards against regression of the original bug. The behavioral change (separating jwksAllowPrivateIP from protectedResourceAllowPrivateIP) is clearly documented in the PR description.

The main pre-existing gaps to track: (1) MCPServer and MCPRemoteProxy CRD paths still don't propagate ProtectedResourceAllowPrivateIP through runner.WithOIDCConfig, and (2) the downstream auth factory ORs both fields into a single AllowPrivateIP, limiting the practical granularity of the separation.

---

Generated with Claude Code

[jhrozek]

LGTM -- clean bug fix with good test coverage