vMCP ignores configured backend timeouts

[christensenjairus]

Bug description

vMCP parses, defaults, validates, and documents operational.timeouts, but the configured values are not applied to backend operations. Backend clients instead use hard-coded 30-second HTTP timeouts, and the incoming vMCP HTTP server independently applies a 30-second write deadline to MCP POST responses.

As a result, a healthy backend tool that needs longer than 30 seconds is disconnected even when its workload has a larger perWorkload timeout.

Reproduction

Configure a backend with a deliberately slow tool and a longer timeout:

operational:
  timeouts:
    default: 30s
    perWorkload:
      slow-backend: 240s

Invoke a tool on slow-backend that returns after more than 30 seconds.

Observed with ToolHive v0.43.0:

• Calling the backend directly succeeds after more than 30 seconds.
• Calling the same tool through vMCP closes the connection at approximately 31 seconds with an empty response.

Expected behavior

• Backend operations use the matching perWorkload timeout, falling back to operational.timeouts.default.
• The timeout applies consistently to Legacy session, Modern, streamable-HTTP, and SSE operation paths.
• A longer backend timeout is not defeated by the incoming server's write deadline.
• Non-MCP routes and actual response writes retain bounded server-side deadlines.

Additional context

The configuration contract already describes TimeoutConfig.Default as the default timeout for backend requests and exposes PerWorkload overrides. This appears to be missing runtime plumbing rather than a new configuration feature.