fix(deps): declare direct zod dependency in filesystem, memory, and sequential-thinking

[Parker-Fawcett]

Description

@modelcontextprotocol/server-filesystem, @modelcontextprotocol/server-memory, and @modelcontextprotocol/server-sequential-thinking all import zod directly at runtime (import { z } from "zod" in their entrypoints) but do not declare zod anywhere in their package.json. This PR adds "zod": "^4.0.0" to each package's dependencies and syncs the root lockfile.

No runtime code is changed — this is packaging metadata only.

Server Details

• Server: filesystem, memory, sequentialthinking (packaging only)
• Changes to: package.json dependency metadata

Motivation and Context

Fixes #4288.

Issue #4288 reported ERR_MODULE_NOT_FOUND: Cannot find package 'zod' under pnpm strict resolution, originally attributed to a dual dependencies/peerDependencies declaration. That dual declaration has since been removed from server-everything (af15c68), but the underlying failure mode persists on current main in its inverse form: three servers consume zod as an undeclared direct dependency.

Evidence on current main:

• src/filesystem/index.ts:13, src/memory/index.ts:6, src/sequentialthinking/index.ts:5 each do import { z } from "zod", yet none of the three packages list zod in dependencies or peerDependencies.
• Installing a packed tarball of server-memory as a consumer dependency and tracing resolution shows import.meta.resolve('zod') landing in a hoisted store slot rather than any edge declared by the server package. The server only starts because modern pnpm/npm defaults hoist or auto-install peer-resolved packages; under the reporter's configuration (pnpm with enableGlobalVirtualStore) and other strict linkers, resolution fails exactly as traced in zod declared in both dependencies and peerDependencies causes ERR_MODULE_NOT_FOUND with pnpm strict isolation #4288.

The fix matches the existing convention established for server-everything ("zod": "^4.0.0"), which satisfies the SDK's peer range (^3.25 || ^4.0).

How Has This Been Tested?

• npm run build --workspaces: all four TS packages compile clean.
• Full vitest suites pass: filesystem 152/152, memory 50/50, sequentialthinking 14/14.
• Packed server-memory post-fix, installed it into a clean consumer project under pnpm 11.22, and drove it over stdio JSON-RPC: initialize handshake completes normally ("Knowledge Graph MCP Server running on stdio"), and the published artifact's package.json now declares {"@modelcontextprotocol/sdk":"^1.30.0","zod":"^4.0.0"}.
• Not tested inside an LLM client GUI; verification was direct JSON-RPC over stdio plus unit suites, which fully covers a dependency-metadata change.

Breaking Changes

None. Consumers' resolved versions are unchanged today (the hoisted zod 4.x already satisfies ^4.0.0); the declaration only makes the existing runtime requirement explicit so strict resolvers can satisfy it.

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 Protocol Documentation
• My changes follows MCP security best practices
• I have updated the server's README accordingly (not applicable — no user-facing behavior change)
• I have tested this with an LLM client (see How Has This Been Tested — verified via direct JSON-RPC stdio instead; N/A for packaging-only)
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling (N/A — no runtime code changed)
• I have documented all environment variables and configuration options (N/A)

Additional context

Why one commit across three packages + lockfile: the lockfile entries are the mechanical consequence of the declarations; splitting them out would create intermediate commits with drifted lockfiles. This follows the repo precedent of landing cross-server dependency changes as a single commit (e.g. "bump packages to 1.29.0 SDK").

Suggested follow-up (happy to do it in a separate PR if useful): a small CI guard that fails when a workspace imports a bare package specifier absent from that package's dependencies, which would catch this class of regression at PR time.

[Parker-Fawcett]

Transparency note while this sits in review: two earlier PRs targeting the same fix exist and are still open — #4289 and #4291 (both from early June). I missed them when opening this one because my survey of open PRs was capped below their numbers; flagging them here rather than leaving three competing diffs for maintainers to triage silently.

How this PR differs, for whoever reviews:

• Based on current main. The June PRs predate the removal of src/gdrive/src/postgres and the SDK ^1.30.0 bump, so their lockfile hunks conflict with today's tree.
• Same dependency change (zod": "^4.0.0" in filesystem, memory, sequentialthinking).
• Includes end-to-end verification: packed tarball installed into a clean consumer project under strict pnpm, server boots, published artifact metadata confirmed.
• Fresh evidence in zod declared in both dependencies and peerDependencies causes ERR_MODULE_NOT_FOUND with pnpm strict isolation #4288 today shows this failing on plain npx -y @modelcontextprotocol/server-filesystem, i.e. the default install path — not just pnpm strict mode.

Happy to withdraw this in favor of either earlier PR if a maintainer prefers first-in-queue — just say so and I'll close immediately. Otherwise happy to rebase whichever of the three you pick.