[BUG] Edit/Write replace files via rename (new inode), so editor file watchers never fire — external changes invisible, then clobbered by autosave

Summary

The Edit/Write tools write via temp-file + rename rather than modifying in place. The path is unchanged but the inode is new, so any watcher bound to the original inode never fires. The editor keeps showing stale content and believes its buffer is clean; the next autosave then overwrites the agent's change with no conflict prompt.

Related but distinct: #87056 reports the same symptom as a race and asks for collision detection / merge. This is a narrower root cause — the editor is not losing a race, it is never notified.

Measured evidence

macOS 26.6.2, VS Code 1.135.0, Claude Code in the VS Code extension.

inode BEFORE : 5588409
(agent Edit applied to the same path)
inode AFTER  : 5588677

Same path, different file object.

Failure chain (silent)

1. File open in the editor; buffer = A, clean.
2. Agent writes B via atomic replace → disk = B, new inode.
3. Inode-bound watcher never fires → editor still shows A and still considers the buffer clean, so it has no reason to reload.
4. User types → buffer A′ becomes dirty.
5. files.autoSave: "afterDelay" writes A′ ~1s later.
6. B is lost. No conflict dialog — the editor believes A′ descends from current disk state.

Why it is intermittent

Workspace folders get a recursive directory watcher, which does observe the rename, so in-workspace files usually reload. Files opened outside any workspace folder are watched individually and reproduce it every time — e.g. plan files under ~/.claude/plans/, which the user reads while the agent edits them.

Repro

1. Open a file that lives outside the VS Code workspace folder.
2. Have Claude Code Edit it.
3. stat -f %i <path> before/after → inode differs; the editor does not reload.
4. Type a character; with autoSave on, the agent's edit is gone.

Impact

Silent data loss — no error, no prompt, nothing in the UI. Encountered on both a personal project and a workplace codebase.

Suggested fix

Write in place (open + truncate + write to the same inode) so watchers observe the modification. If atomic replace is retained for crash-safety, consider copying content back into the original inode after the rename, or emitting an explicit change signal that editors / IDE extensions can subscribe to.