feat: dual-era support for the 2026-07-28 protocol version

[sideeffffect]

Groundwork for 2026-07-28 (the "modern" era) support, making chimp dual-era. This is the foundation the reviews on #234 and #235 pointed to (relates to #163).

Why

Per the 2026-07-28 versioning compatibility matrix, server/discover and extensions like Tasks belong to the modern era. Today chimp is legacy-only, so — as @kubinio123 noted on #235 — a modern/dual-era client calling server/discover should get an error. This PR makes chimp genuinely dual-era, so answering server/discover (and recognising modern per-request versions) becomes correct.

What

• ProtocolVersion.V2026_07_28 + a supported list. Latest still points at the latest legacy revision used by the initialize handshake, so legacy negotiation is unchanged.
• server/discover → DiscoverResult (supported versions, capabilities, serverInfo in _meta, resultType: "complete", ttlMs, cacheScope).
• Per-request version negotiation: a request declaring _meta["io.modelcontextprotocol/protocolVersion"] that the server doesn't support is rejected with UnsupportedProtocolVersion (-32022) listing the supported versions; a supported/absent version is processed as before (chimp already handles each request statelessly).
• New core types DiscoverResult, CacheScope, ProtocolMeta (the reserved _meta keys).

Addressing the review feedback

• JSON-schema validation (feat: MCP Tasks extension (full: protocol, server execution, client) #234): the new types are validated against the official 2026-07-28 schema in Schema2026ConformanceSpec, mirroring SchemaConformanceSpec — I bundled schema/2026-07-28/schema.json as a test resource.
• Don't break 2025-11-25 (feat: MCP Tasks extension (full: protocol, server execution, client) #234): no fields were added to the shared types (e.g. no extensions on ServerCapabilities); chimp's ServerCapabilities is already a valid subset of the 2026-07-28 one. The 2025-11-25 schema conformance and the legacy initialize path are untouched.
• Extensions as separate packages (feat: MCP Tasks extension (full: protocol, server execution, client) #234): agreed — this PR is the base protocol only; Tasks (feat: MCP Tasks extension (full: protocol, server execution, client) #234) and other extensions would layer on top, ideally as their own modules.

Deliberately out of scope (WIP / follow-ups)

• Modern client mode (the client still uses the legacy initialize handshake).
• HTTP transport-level modern validation (MCP-Protocol-Version header, 400 semantics, era detection).
• resultType on all existing results (modern clients already treat an absent resultType as "complete", so this is backward-compatible).
• Full modern required-field validation (clientCapabilities, -32021) and the tasks/other extension modules.

Tests

Schema2026ConformanceSpec (DiscoverResult + the -32022 envelope vs. the official schema) and McpHandlerSpec cases: server/discover returns supported versions + capabilities + identity; an unsupported version → -32022; a supported modern version is processed; legacy initialize still works. sbt scalafmtCheckAll compile Test/compile compileDocs and the unit suites pass locally. Draft/WIP.

🤖 Generated with Claude Code

[sideeffffect]

Hello @kubinio123 , what do this about adding support for dual-era like this?
I think this would unlock changes from the other two PRs (big thanks that you've already had a look at them too).

[deemwario]

Relevant field data point if useful: I maintain a 2026-07-28-only (not dual-era) MCP server implementation, and one thing worth testing explicitly once server/discover + per-request _meta negotiation land — a conformance sweep against my server (via @hasmcp/mcp-spec-test) surfaced that the current official MCP SDK client doesn't yet speak 2026-07-28's handshake-less negotiation the way the spec describes it ('the official SDK does not yet implement the newest revision' was the conformance tool's own note). So a stock official-SDK client sending a classic initialize will hit your UnsupportedProtocolVersion path even once dual-era support is correct per-spec — which is expected, but worth an explicit test case ("official SDK client → legacy negotiation path") rather than only schema-validating the modern path, since that's the interop gap that actually surfaces first in practice.

We went the other direction on the design question this PR is solving (latest-only rather than dual-era — wrote up the tradeoff here if the reasoning is useful as a comparison point, not a suggestion to change course) — dual-era is clearly the more correct choice for a general-purpose client-facing library like this, ours was a narrower bet made for a specific reason.