feat(vmcp): plumb operational.timeouts.default into request timeouts

[thomasandal]

Problem

The CRD field VirtualMCPServer.spec.config.operational.timeouts.default is documented as "the default timeout for backend requests" but is currently dead config. It's defined (pkg/vmcp/config/config.go:524), defaulted (pkg/vmcp/config/defaults.go:54) and validated (pkg/vmcp/config/validator.go:367), but never read by any request-path code.

The actual ceiling is hardcoded in two places:

1. Outbound — vmcp → backend MCPServer:
   pkg/vmcp/session/internal/backend/mcp_session.go:35

   defaultBackendRequestTimeout = 30 * time.Second

   Applied at lines 298–304 to the streamable-http http.Client.Timeout and the mark3labs SDK's WithHTTPTimeout.

2. Inbound — vmcp's own http.Server:
   pkg/vmcp/server/server.go:53,59

   defaultReadTimeout  = 30 * time.Second
   defaultWriteTimeout = 30 * time.Second

   Applied at lines 696–697 in Server.Start.

User-visible symptom: any tool call that takes >30s upstream returns 502 from any nginx in front of vmcp, even with operational.timeouts.default: 120s set on the CR. Heavy ClickHouse aggregations, deep Perplexity research, and large GitHub searches are the common cases.

I confirmed both layers fire by bisecting in production: 28s queries succeed; 35s queries 502'd until BOTH timeouts were lifted. mcp-clickhouse pod logs show the upstream completing the query in all cases — vmcp hangs up before the response can be relayed.

Change

Plumb operational.timeouts.default (already a time.Duration-castable custom Duration type) through to both layers:

• pkg/vmcp/session/internal/backend/mcp_session.go — NewHTTPConnector(registry, requestTimeout) and createMCPClient(..., requestTimeout) accept a time.Duration. 0 falls back to the existing 30s constant. SSE backends are unaffected.
• pkg/vmcp/session/factory.go — new WithBackendRequestTimeout(d) factory option, mirrors the existing WithBackendInitTimeout shape. NewSessionFactory pre-applies opts to a sentinel struct so the connector can be constructed with the configured timeout (option funcs are pure setters, double-application is idempotent).
• pkg/vmcp/server/server.go — new Config.RequestTimeout. When > 0, overrides both ReadTimeout and WriteTimeout. SSE GET routes still clear their per-request write deadline via transportmiddleware.WriteTimeout (net/http: no way of manipulating timeouts in Handler golang/go#16100), so SSE behavior is unchanged.
• pkg/vmcp/cli/serve.go — reads cfg.Operational.Timeouts.Default, passes it to createSessionFactory (forwarded via the new option) AND sets serverCfg.RequestTimeout. Nil-safe — defaults preserved when Operational or Timeouts is unset.

Tests in pkg/vmcp/session/internal/backend/mcp_session_test.go and pkg/vmcp/cli/serve_test.go pass 0 for the new arg to preserve the prior behavior.

Test plan

• go build ./... — clean.
• go test ./pkg/vmcp/session/... ./pkg/vmcp/cli/... ./pkg/vmcp/server/... — all green.
• Built ko image from this branch and ran in production for ~30 minutes against a homelab cluster: 100 fresh-connection probes return 401 (no 5xx regressions); previously-502'ing 35s ClickHouse query now returns 200 in 35s. The remaining ceiling at ~60s is the operator-side streamable_proxy.defaultRequestTimeout (already env-overridable via TOOLHIVE_PROXY_REQUEST_TIMEOUT).

Notes

• Backwards-compatible: the new requestTimeout/RequestTimeout parameters default to 0, which preserves the existing 30s constants. Existing callers that don't pass anything see no change.
• Doesn't address the operator-side pkg/transport/proxy/streamable/streamable_proxy.go:35 60s default (already overridable via TOOLHIVE_PROXY_REQUEST_TIMEOUT env on the proxy container). That's a separate hop for a separate PR if anyone wants symmetry.