fix(vmcp): bound initialize to healthCheckTimeout

[RaviTharuma]

Cross-links

• Issue: bug(vmcp): Ready and /health stay OK while initialize can hang past client timeouts #6345
• Maintainer direction (bound initialize / document Ready vs health): bug(vmcp): Ready and /health stay OK while initialize can hang past client timeouts #6345 (comment)
• PR announcement: bug(vmcp): Ready and /health stay OK while initialize can hang past client timeouts #6345 (comment)

Summary

VirtualMCPServer Ready and GET /health could stay OK while a new client's
initialize hung past typical gateway timeouts (12s) with a 0-byte response.

Those signals are different operations: /health is liveness, Ready is the
last ListCapabilities probe, and initialize waits on backend handshakes
(per-backend 30s, concurrency 10). This does not flip Ready//health on
initialize failure (that would flap). It bounds the handshake.

• Overall MakeSession budget defaults to 10s (same as CRD
  healthCheckTimeout)
• Wire WithSessionInitTimeout from failureHandling.healthCheckTimeout
  when set
• Unfinished backends are skipped (best-effort session), not a hard error
• Document Health vs Ready vs initialize

Fixes #6345

Type of change

• Bug fix
• New feature
• Refactoring (no behavior change)
• Dependency update
• Documentation
• Other (describe):

Test plan

• go test -ldflags=-extldflags=-Wl,-w ./pkg/vmcp/session/ -run 'TestWithSessionInitTimeout|TestNewSessionFactory_SessionInitTimeout|TestNewSessionFactory_BackendInitTimeout|TestNewSessionFactory_AllBackendsFail'
• CI unit tests
• After merge: a slow backend must not hold initialize past
  healthCheckTimeout; /health remains liveness-only

API Compatibility

This does not change the CRD schema. healthCheckTimeout already exists; it
now also bounds session initialize.

Does this introduce a user-facing change?

Yes. New vMCP sessions finish initialize within healthCheckTimeout
(default 10s). Slow backends are omitted from that session instead of
blocking the client. /health is documented as liveness only.

Special notes for reviewers

Direction from #6345: Ready is ListCapabilities, initialize is a different
handshake. Bounding + documenting is the agreed path; a separate SessionReady
signal is left for a follow-up if you want it.

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[RaviTharuma]

Implements #6345 per maintainer direction.

Cross-links:

• Issue: bug(vmcp): Ready and /health stay OK while initialize can hang past client timeouts #6345
• Maintainer comment: bug(vmcp): Ready and /health stay OK while initialize can hang past client timeouts #6345 (comment)
• Issue PR note: bug(vmcp): Ready and /health stay OK while initialize can hang past client timeouts #6345 (comment)

[RaviTharuma]

Automated fix: rebased onto main (20 commits). Remaining golangci findings are in operator files this PR does not touch (gci/staticcheck SA1019).

[codecov]

Codecov Report

❌ Patch coverage is 72.22222% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 77.67%. Comparing base (b48013e) to head (e14a014).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/vmcp/cli/serve.go	0.00%	5 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6380      +/-   ##
==========================================
- Coverage   77.69%   77.67%   -0.02%     
==========================================
  Files         752      756       +4     
  Lines       72717    72806      +89     
==========================================
+ Hits        56500    56555      +55     
- Misses      16212    16246      +34     
  Partials        5        5              

☔ View full report in Codecov by Harness.
📢 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.