fix(filesystem): prefer direct overwrite before copy fallback - #2

Description

When fs.rename fails with EPERM, try an in-place fs.writeFile overwrite before using fs.cp({ force: true }). The direct overwrite avoids the destination unlink—and the associated symlink race window—in the common Windows lock case. fs.cp remains the final fallback for locks that allow delete sharing but not write sharing.

The filesystem tests now cover both public call paths, verify that the safer direct overwrite avoids fs.cp when it succeeds, and verify the copy fallback when direct overwrite is blocked.

Server Details

• Server: filesystem
• Changes to: write_file and edit_file replacement behavior and tests

Motivation and Context

This applies the fallback ordering requested in the maintainer review on modelcontextprotocol#3296 and follows the contribution request on modelcontextprotocol#3610.

How Has This Been Tested?

npx vitest run src/filesystem/__tests__/lib.test.ts
✓ 52 tests passed

npm run build --workspace @modelcontextprotocol/server-filesystem
✓ build passed

The four focused direct-overwrite and fallback tests failed before the implementation change and pass afterward.

Breaking Changes

None.

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 which causes existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Protocol Documentation
• My changes follow MCP security best practices
• I have updated the server's README accordingly
• I have tested this with an LLM client
• My code follows the repository's style guidelines
• New and existing focused tests pass locally
• I have added appropriate error handling
• I have documented all environment variables and configuration options

Additional context

The normal atomic rename path is unchanged. The documented non-atomic fs.cp behavior is retained only as the last fallback.