Bumps the conformance harness pin from b18aa918 to 4944b268 (0.2.0-alpha.8 + conformance#372, neither published to npm yet — same sha256-verified pkg.pr.new mechanics as the previous pin).

#372 changes skip semantics: a check whose prerequisite is missing — a fixture tool the server doesn't ship, or a capability the server advertises but then rejects — now fails with a "Not testable:" message instead of silently skipping outside the pass/fail denominator. That makes one more unimplemented surface visible as a baselined known failure:

• server-stateless now fails its 3 subscriptions/listen MUST checks (new entry in both expected-failures files). The everything-server's legacy resources/subscribe handlers make it advertise resources.subscribe in server/discover, while subscriptions/listen answers -32601 — under Fixes to stdio_client to support Windows more robustly #372 that's claims-but-doesn't-serve, a failure. The entry burns down when the listen runtime lands (Implement SEP-2575: Make MCP Stateless #2804). The two listChanged SHOULD checks remain legitimately skipped (the capability is declared false, which Fixes to stdio_client to support Windows more robustly #372 still treats as honest feature absence).
• The tasks-* scenarios fail with higher check counts (their "no task created" cascade skips now fail too), but they were already baselined — no entry changes.
• tasks-status-notifications still skips unconditionally under Fixes to stdio_client to support Windows more robustly #372 and must stay unbaselined.
• Client legs are unaffected (421/370 checks pass, zero warnings, both exit 0).

Motivation and Context

Same goal as #3030, finished by the upstream half: #3030 made the filtered-out scenarios run; #372 makes the prerequisite-gap checks inside running scenarios count. After both, the only remaining green-without-evidence surfaces are the ones the harness deliberately exempts.

How Has This Been Tested?

Replicated all six CI legs locally against the new pinned tarball (sha256-verified), exactly as CI invokes them: the four server legs and both client legs exit 0 with "Baseline check passed", with server-stateless failing only the 3 listen checks (25 still passing) and all other failures matching the existing baseline. Also confirmed the discovery state before the baseline update: only server-stateless was newly unexpected; no stale entries; no warnings anywhere.

Breaking Changes

None — CI configuration only.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

• The server-stateless waiver carries a real masking cost, called out in the baseline comment: while listed, new failures in the scenario's other 25 (currently passing) envelope/error-handling checks are also absorbed, because the baseline is per-scenario. The trade is deliberate — a visible, forced-burn-down known failure for the listen gap beats the pre-Fixes to stdio_client to support Windows more robustly #372 state where the same gap was invisible — but it makes landing the listen runtime (Implement SEP-2575: Make MCP Stateless #2804) the way to get those 25 checks back under guard.
• The capability inconsistency the harness is flagging is real, not a harness artifact: on the 2026 wire the server advertises resources.subscribe while the subscribe methods themselves answer 404/-32601 there. Implementing listen resolves it from one side; era-aware capability reporting in server/discover would resolve it from the other.

AI Disclaimer