Pin the newest sessionful MCP revision with tests

The endpoint promises to serve protocol revisions "2024-10-07 through
2025-11-25" -- in src/constants.ts, twice in src/mcpHandler.ts, and in the
Readme -- but nothing tested the top of that range. Every sessionful probe used
2025-06-18 as its stand-in, so the claim held only because the pinned SDK
happens to list 2025-11-25 in SUPPORTED_PROTOCOL_VERSIONS.

That gap matters because losing the revision would be silent rather than loud:
a client asking for a revision the handler cannot serve is answered with an
older one it can, so an SDK bump that dropped 2025-11-25 would start
downgrading clients with every test still green.

Adds three unit cases and one live integration case that initialize at
2025-11-25 and assert the negotiated version comes back unchanged, plus one
that drives a follow-up request with the matching MCP-Protocol-Version header
so the router's own version filter is covered too. The version is a hardcoded
literal, not the SDK's LATEST_PROTOCOL_VERSION, which would make the assertions
tautological. Verified by mutation: pointing the constant at an unserved
revision fails all three unit cases.

Prompted by issue #329, which reported initialize at 2025-11-25 hanging. It
does not reproduce -- this is the gap that investigation exposed, and it stands
on its own merits regardless of how that issue is answered.

The new integration case terminates its session instead of leaking it. Every
live session is a subscriber the plugin pushes listChanged notifications to on
each vault write, and an extra one left open was enough to make the vault_patch
frontmatter read-back race: 2 failures in 4 full-suite runs without the DELETE,
0 in 4 with it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>