fix(filesystem): handle invalid stdio JSON-RPC frames

[kgarg2468]

Summary

• replace the filesystem server stdio transport with a defensive line-framed transport
• return JSON-RPC parse/invalid-request errors for malformed or oversized frames
• recover after malformed/oversized input so later JSON-RPC messages still process

Fixes #4206.
Fixes #4207.

Tests

• cd src/filesystem && npx vitest run tests/stdio-transport.test.ts
• cd src/filesystem && npm run build
• cd src/filesystem && npx vitest run tests/stdio-transport.test.ts tests/startup-validation.test.ts
• git diff --check

[slegarraga]

Nice, defensive framing here — recovering after a bad frame is the right behavior.

One layering thought for the maintainers, since I just looked at the same class of bug in the SDK: the reason this needs ~240 lines of custom transport is that the SDK's own StdioServerTransport drops a malformed-but-recoverable frame (e.g. a request missing jsonrpc) — it routes the validation error to onerror but never replies, so a client tracking that id hangs. That's filed as modelcontextprotocol/typescript-sdk#2247, and a fix there makes the SDK transport reply with a JSON-RPC Invalid Request (-32600) when the offending message has a recoverable id.

If that lands in the SDK, the filesystem server (and every other server) could keep using the stock StdioServerTransport instead of maintaining a parallel one. Might be worth deciding where this should live long-term — a per-server transport works, but the SDK-level fix removes the need for it everywhere. Happy to share details from the SDK side if useful.

[LuuOW]

Technical audit: Verified MCP server implementation for consistency with current SDK patterns.