fix(file): resolve 1ms timestamp race in sequential file edits

[TakashiKyoto]

Issue #8624

Issue Fixed in this PR:

Sequential file edits fail with "File modified since it was last read" showing 1-10ms timestamp differences, even with no external modifications.

Root cause: FileTime.read() stores new Date() instead of the file's actual mtime. After writes, filesystem mtime updates can lag slightly (especially Windows NTFS, and WSL2), causing false positives in assert().

Fix:

• FileTime.read() now accepts optional mtime parameter
• All write operations pass actual file mtime after writes
• Added 10ms tolerance in assert() for edge cases