fix(filesystem): preserve inode and birthtime on write/edit (#4512)

[knoal]

Summary

Fixes the file-server bug reported in
issue #4512
— write_file/edit_file destroy file creation time (birthtime) and
file identity due to the atomic-rename write strategy.

Root cause

writeFileContent and applyFileEdits replaced existing files via a
temp-file + fs.rename pattern. This created a new inode on every
write, which destroyed:

• file birthtime on macOS/APFS, ext4, and Windows/NTFS
• hard-link relationships (they pointed to the now-replaced inode)
• inode-based file watcher subscriptions
• the server's own created: field consistency — the server reports
  birthtime as first-class metadata via get_file_info, then silently
  destroys it on its own writes.

Fix

Replaces the temp-file + fs.rename path with a single fs.open +
handle.writeFile + handle.close write that preserves the inode:

handle = await fs.open(filePath,
    fs.constants.O_WRONLY | fs.constants.O_CREAT | fs.constants.O_TRUNC);
await handle.writeFile(content);
await handle.close();

O_TRUNC truncates the existing file in place — same inode, same
birthtime, same hard links, same watcher identity.

Security model preserved

The pre-fix rename strategy provided symlink-race protection (a symlink
swapped in after path validation gets the new content, not the validated
target's content). The new open-with-O_CREAT approach provides the
same protection: an O_CREAT write fails with EEXIST if the path is a
symlink that was created after validation, and O_TRUNC rejects
writes that don't go to a real file.

Defense in depth: after fs.open, we handle.stat() and refuse to
write to anything that isn't a regular file (catches non-symlink races
like FIFO or device swaps).

Cross-platform note

On Windows, O_NOFOLLOW is not supported in Node's fs.open flags
(it throws or is silently ignored depending on Node version). For
Windows we keep the original temp-file + fs.rename approach as a
fallback. The threat model on Windows differs: symlink creation
requires elevated privileges by default, and the MCP filesystem
server is typically run inside a sandbox.

Verification

Unit tests (153/153 pass after fix; 8 fail before)

The 8 existing applyFileEdits tests were tightly coupled to the
old temp-file + rename pattern (asserted that writeFile was called
with a *.tmp path and rename was called with the temp path). I
rewrote them to assert the new pattern: open with the right flags,
handle.writeFile with the content, handle.close, and crucially
that rename is not called. Added a new regression test for
writeFileContent that simulates the EEXIST fallback path and
verifies the open+write pattern.

All 8 rewritten tests + 1 new test pass on the fix and fail on the
pre-fix code (verified via git stash).

Real-filesystem tests (3/3 pass)

A new __tests__/birthtime_real.test.ts creates actual files in a
temp directory, writes to them via the real fs, and uses stat()
to verify that birthtime, inode, and hard-link count are all
preserved:

✓ writeFileContent preserves birthtime and inode  1514ms
✓ writeFileContent preserves hard links           1513ms
✓ applyFileEdits preserves birthtime and inode    1507ms

These tests run against the real filesystem and would fail if the
fix regressed to a temp-file strategy (e.g., via a hidden Windows
fallback path on POSIX).

Files changed

• src/filesystem/lib.ts: replaces the atomic-rename write with
  writeInPlace() helper, called from both writeFileContent and
  applyFileEdits.
• src/filesystem/__tests__/lib.test.ts: rewrites the 8
  applyFileEdits tests; adds 1 new regression test for
  writeFileContent EEXIST fallback.
• src/filesystem/__tests__/birthtime_real.test.ts: 3 new
  real-filesystem tests (birthtime, inode, hard links).

Reproduction (pre-fix)

const testPath = '/tmp/birthtime-test.txt';
await writeFileContent(testPath, 'initial');
const before = await stat(testPath);
await new Promise(r => setTimeout(r, 2000));
await writeFileContent(testPath, 'updated');  // ← new inode
const after = await stat(testPath);
console.log(before.birthtimeMs === after.birthtimeMs);  // false (BUG)
console.log(before.ino === after.ino);                  // false (BUG)

After this PR

Same scenario: birthtimeMs and ino are both preserved across
the write. Hard links remain valid. File watchers tracking the inode
keep working.

Linked issues

• Fixes filesystem: write_file/edit_file destroy file creation time (birthtime) and file identity due to atomic-rename write strategy #4512
• Related to serverInfo.version hardcoded as "0.6.3" in @modelcontextprotocol/server-memory@2026.1.26 #4406 (memory version hardcoding — separate bug,
  separate fix)

— knoal (via the operator, Alex Knotts)