Sequential edits to same file can silently drop first edit

Description

When making two rapid sequential edits to the same file, the first edit can be silently lost. The second edit succeeds, but the file state after both edits only reflects the second change.

Reproduction

1. Read a file
2. Make an Edit to add an import line near the top of the file
3. Immediately make a second Edit to add a registration call later in the same file
4. The Edit tool reports: File has been modified since read, either by the user or by a linter. Read it again before attempting to write it.
5. On re-read, the first edit (import line) is missing — only the original file content is present
6. The second edit (registration call) was applied successfully

Environment

• No linter, formatter, file watcher, or git hook is configured in the repo
• No .eslintrc, prettier, biome, lint-staged, or husky configuration exists
• No VS Code workspace settings or editor integrations active
• The file was not modified by any external process

Expected behavior

Both edits should be applied, or the second edit should block/fail cleanly until the first edit is fully persisted.

Actual behavior

The first edit is silently dropped. The file-change detection fires between edits, and the intermediate state seen on re-read does not include the first edit. This causes unnecessary rework (re-applying the lost edit).

Workaround

Combine both changes into a single Edit call rather than making sequential edits to the same file.