fix(filesystem): verify write_file output landed on disk (#4138)

[0ywfe]

Summary

Closes #4138 — write_file in the filesystem server silently returned success on Windows even though no bytes reached disk. Callers received "File created successfully" with no way to detect the failure.

This change adds a post-write verification step inside writeFileContent:

1. fs.stat the target after the write completes.
2. Compare on-disk size to Buffer.byteLength(content, 'utf-8').
3. Throw an explicit error on miss / mismatch.

The fix runs for both write paths (wx fresh-create and EEXIST atomic-rename) and converts the silent failure into a useful error message.

Why this approach

The host-side root cause varies by environment (the reporter ruled out NTFS permissions, Defender, Controlled Folder Access, OneDrive, paths-with-spaces — and reproduced on both isUsingBuiltInNodeForMcp: true and system Node). What's consistent is the failure mode: fs.writeFile resolves with no error and nothing is on disk.

Rather than chase the host layer, this closes the gap at the boundary we control. The verification is platform-agnostic — silent success is the wrong contract on any OS — so the same guard also catches partial writes, antivirus quarantine mid-write, and rename-to-wrong-path bugs.

Test plan

• npm test — all 150 existing tests pass.
• New tests in src/filesystem/__tests__/lib.test.ts (`writeFileContent` block):
  • Existing happy-path test extended to mock fs.stat and assert it is consulted.
  • Regression for [filesystem] write_file silently returns success but never writes to disk on Windows #4138: mocks fs.writeFile to resolve and fs.stat to reject with ENOENT, asserts a clear "reported success but the file is missing on disk" error.
  • Size mismatch: mocks fs.stat to report 0 bytes for non-empty content, asserts size-mismatch error.
  • Multibyte UTF-8 sanity: confirms Buffer.byteLength('héllo 🌍', 'utf-8') is the right yardstick.
• npm run build — TypeScript clean.

Out of scope

• Pinpointing the underlying Windows-host cause. That is worth a separate investigation; this PR is the boundary fix that makes the failure detectable today.
• Applying the same verification to edit_file / applyFileEdits. The reporter confirms edit_file works correctly on the same paths, so it is not affected by the same failure mode. If desired in a follow-up, the same fs.stat-after-write check could be extracted into a helper.

Files

• src/filesystem/lib.ts (+22)
• src/filesystem/__tests__/lib.test.ts (+37, -2)