[BLOCKED] Remove the vMCP Modern stateless dispatch kill-switch

[JAORMX]

⛔ BLOCKED — DO NOT MERGE

vMCP's Modern dispatcher does not implement subscriptions/listen. Merging this makes vMCP
unreachable for any client that wants server→client traffic (elicitation, sampling, progress,
logging, list_changed). Draft deliberately, so the analysis is reviewable rather than re-derived.

Summary

Config.ModernDispatchEnabled (env TOOLHIVE_VMCP_MODERN_STATELESS, default off) was a temporary safety lever gating whether well-formed MCP 2026-07-28 ("Modern") stateless requests are served by classifyingHandler → dispatchModern or fall through to the SDK path. #5959 asks for its removal before GA.

Both of the issue's stated gates are met — #5837's dual-era conformance harness landed, go-sdk v1.7 was adopted via #5993 — and the sequencing @jhrozek asked for on #6009 is satisfied. So this looked ready. It is not, and the reason is the substance of this PR.

The blocker

Removing the server/discover exemption is what breaks the product — not removing the -32022.

That exemption was added in #6009 to keep version negotiation possible while the switch was off. It turns out to have been doing load-bearing work well beyond conformance: it is what steered Modern-first clients onto Legacy.

1. go-sdk v1.7's Connect is Modern-first: it POSTs server/discover with MCP-Protocol-Version: 2026-07-28.
2. Switch off (today): the exemption passes that to the SDK's stateful server, which answers Legacy-only supportedVersions → client negotiates Legacy → everything works.
3. Modern unconditional (this PR): dispatchModernDiscover answers supportedVersions: ["2026-07-28","2025-11-25"] (newModernDiscover, modern_envelope.go) → client negotiates Modern.
4. mcpcompat's Initialize installs the list-changed handlers unconditionally (client.installNotificationHandlers), and go-sdk opens the standalone stream whenever any handler is set → client POSTs subscriptions/listen.
5. dispatchModern's method switch has no subscriptions/listen case (modern_dispatch.go:80-110 covers tools/*, resources/*, prompts/*, completion/complete, ping, server/discover) → -32601 → go-sdk treats Connect as failed and tears the connection down.

Observed wire trace:

REQ POST proto="2026-07-28" method=server/discover
  RESP 200 {...,"supportedVersions":["2026-07-28","2025-11-25"],...}
REQ POST proto="2026-07-28" method=subscriptions/listen
  RESP 404 {"error":{"code":-32601,"message":"method not found"},...}

This is pre-existing, not introduced here

Confirmed by control: with this change stashed, setting ModernDispatchEnabled: true on clean main reproduces identical failures. The kill-switch has been masking a hole that already existed. Please read the 20 regressions below as exposed, not caused.

pkg/vmcp/session/factory.go already documents this exact hole for the backend edge — "its push channel is subscriptions/listen, which vMCP does not implement". This exposes the same hole on the client edge.

So #5959 has an unstated third gate: implement subscriptions/listen in dispatchModern, or otherwise stop advertising Modern to clients that need a push channel. That is a Modern push-channel design task, not kill-switch work, and probably wants its own issue under #5743.

Suggested path, and one fix to avoid

Implement subscriptions/listen in dispatchModern (or decide deliberately how vMCP should present Modern to clients needing a push channel), then rebase this on top.

Answering subscriptions/listen with a benign stub is not a fix. Modern clients would connect successfully and then receive a silently non-functional notification channel — no elicitation, no sampling, no progress, no list_changed, and no error to indicate it. That is strictly worse than the loud failure above, and it is the "silent no-op" anti-pattern .claude/rules/go-style.md calls out by name. Flagging it because it is the obvious shortcut and it would be very hard to notice in review.

Type of change

• Other (describe): blocked feature removal, opened as draft for review of the analysis

Test plan

• Linting (task lint) — 0 issues after task lint-fix (3 gci failures first, from struct-field alignment left over where the field was deleted)
• go vet ./... — clean. Note the e2e files carry no build tag (just package e2e_test), so plain vet does cover them.
• task build — pass
• Unit tests (task test) — FAILS, see below
• E2E tests — could not run (no container runtime in this environment)

20 top-level regressions, all one root cause, all absent from a clean-tree baseline (failure sets diffed with and without the change):

Package	Tests
pkg/vmcp/server (5)	TestForwarding_Elicitation_RealBackend, TestForwarding_Sampling_RealBackend, TestForwarding_Sampling_RealBackend_SessionIsolation, TestForwarding_Progress_RealBackend, TestForwarding_Logging_RealBackend
test/integration/vmcp (15)	TestVMCPServer_TypeCoercion, …_TypeCoercion_NestedAndArrays, …_StructuredContent, …_StructuredContent_IntegerComparisonError, …_ConflictResolution, …_PassthroughHeaders, …_CompositeToolNonStringArguments, …_DefaultResults_{ConditionalSkip,ContinueOnError,NestedStructure}, …_Telemetry_CompositeToolMetrics, …_TwoBoundaryAuth_HeaderInjection, TestRegression_Over1000Tools_CompleteSetReceived, TestRegression_SetSessionTools_FixedAtInitialize_NoMidSessionReconciliation, TestRegression_SlidingSessionTTL_TrafficKeepsSessionAlive

Failing on baseline too, unrelated: pkg/api, pkg/secrets/keyring, test/e2e, all 11 cmd/thv-operator/test-integration/*, 2 test/e2e/thv-operator/*.

API Compatibility

• This PR does not break the v1beta1 API.

No CRD or api/v1* type is touched. The kill-switch was env-only and was never wired to a CRD field, so nothing in the operator API surface changes. server.Config/ServerConfig lose a Go field and the TOOLHIVE_VMCP_MODERN_STATELESS env var is removed.

Does this introduce a user-facing change?

Yes — and it is the reason this is blocked. vMCP would serve MCP 2026-07-28 unconditionally, and the env var would no longer be honoured. In its current form that also makes vMCP unreachable for clients needing a server→client channel.

Special notes for reviewers

@jhrozek — this removes two things you added in #6009, and they deserve separate verdicts:

• The -32022 UnsupportedVersionError removal is sound. It answered exactly one condition — "vMCP supports this revision but has chosen not to serve it" — which cannot arise once the switch is gone. Every genuine version-grounds rejection still happens, earlier and unchanged, in mcpparser.ClassifyRevision.
• The server/discover exemption is the interesting part. It was documented as a conformance measure (so a client could still negotiate down), but in practice it was silently pinning Modern-first clients to Legacy — which is a much stronger role, and the thing that keeps vMCP working today. Your read on whether that was intentional would be valuable.

Why the tempting middle option does not work. Keeping the exemption while dropping the -32022 leaves vMCP serving Modern verbs while denying Modern in its own capability probe — Modern dispatch becomes unreachable for any well-behaved client, which is worse than either end state.

A coverage gap worth attention independently of this PR: the dual-era e2e suite would not have caught this. e2e.RawMCPClient never sends the server/discover probe, so the suite's Modern coverage does not exercise the negotiation path a real SDK client takes.

Silently-vacuous test removed along the way: authz_integration_test.go's buildCedarAuthzServer had to set the switch for TestIntegration_CedarAuthzDenial_ModernPath_IsAudited to reach dispatchModern's call gate at all. That class of test — passing while never touching the path it names — disappears with the switch.

Refs #5959

Generated with Claude Code

[JAORMX]

CI confirms the blocker, and corrects one claim in the description above

E2E Test Lifecycle failed on all three kind versions (1.33.7, 1.34.3, 1.35.1) — identically, and deterministically:

Ran 8 of 146 Specs in 34.348 seconds
FAIL! - Interrupted by Other Ginkgo Process -- 0 Passed | 8 Failed | 0 Pending | 138 Skipped

Zero specs passed. The virtualmcp suite collapses at the first spec in each container. The two genuine failures are both tool-listing assertions, which is exactly what "the client could not complete Connect" looks like from the outside:

• VirtualMCPServer Code Mode → should advertise execute_tool_script alongside the backend tools (virtualmcp_codemode_test.go:111)
• VirtualMCPServer Composite Sequential Workflow → should expose the composite tool in tool listing (virtualmcp_composite_sequential_test.go:144)

The other six are [INTERRUPTED] in [BeforeAll] — collateral from Ginkgo tearing down sibling processes, not independent failures.

This is not a flake, and the shape proves it

Worth stating explicitly, because this repo has had several genuine flakes today (#6026, #6034, a curl reset in helm/kind-action) and a reviewer would reasonably reach for "re-run it":

	Today's flakes	This
Versions affected	1 of 3	3 of 3
Specs passing	139 of 142	0 of 146
Reproducible on re-run	no	deterministic

Correction to the description

The description says the dual-era e2e suite "would not have caught this" because e2e.RawMCPClient never sends the server/discover probe. That is true only of that suite. It gave the impression e2e coverage generally would miss this, which is wrong: the operator virtualmcp E2E suite does catch it, loudly and on every kind version, because it drives real go-sdk clients that do send the probe.

So the coverage gap is narrower than stated — the RawMCPClient-based dual-era specs have a blind spot on the negotiation path, but the k8s E2E tier does not. Fixing that blind spot is still worth doing (a Modern spec that never negotiates is not testing Modern negotiation), just not on the grounds that this defect would otherwise have been invisible.

Everything else in the description stands, including the baseline control showing this is pre-existing rather than introduced here.