[BUG] Edit tool blocked when external process modifies file after read

Bug Description

The Edit tool refuses to edit any file that has been modified since the last Read, with:

File has been modified since read, either by the user or by a linter.
Read it again before attempting to write it.

While this safety check is valuable, it does not distinguish between external modifications and forces a manual Read → Edit cycle every time. This creates a disruptive stop-start workflow in many common development scenarios.

Affected Scenarios

| Trigger | Examples |
|---------|---------|
| Pre-commit hooks | \ruff format\, \prettier\, \black\, \eslint --fix\ |
| IDE auto-format | VS Code format-on-save, IntelliJ auto-format |
| File watchers | \tsc --watch\, \webpack\, \nodemon\ |
| CLI formatters | \cargo fmt\, \go fmt\, \dart format\ |
| User editing | User edits file in their editor during Claude's session |

Steps to Reproduce (pre-commit hook example)

1. Have a pre-commit config with both \ruff check\ and \ruff format\ hooks
2. Read a Python file, then Edit it (introduces a long line)
3. Stage and attempt \git commit\ via Bash tool
4. \ruff check\ fails (e.g., line too long E501)
5. \ruff format\ auto-reformats the file as part of the hook pipeline
6. Attempt to use Edit tool on the same file → blocked
7. Must use Read tool first, then Edit tool again

Expected Behavior

Ideally the Edit tool should handle external modifications more gracefully. Some options:

1. Auto re-read: When file is modified externally, auto-refresh the internal state instead of blocking
2. Diff-aware edit: Apply the edit if the target \old_string\ still exists in the modified file (the edit is still valid)
3. Warn but allow: Show a warning instead of a hard block, letting the agent proceed if the edit target is unambiguous

Option 2 seems most robust — if the \old_string\ to be replaced still matches in the modified file, the edit is safe regardless of what changed elsewhere.

Actual Behavior

Edit tool hard-blocks with an error. The agent must:

1. Notice the error
2. Call Read tool
3. Re-attempt the Edit

This 3-step overhead happens per file, per modification event, and compounds during iterative workflows like commit-fix-recommit loops.

Impact

• Breaks flow during iterative development cycles
• Causes agent to "stop and restart" repeatedly
• Particularly painful with auto-formatting tools that modify files on every failed commit
• Users experience this as the agent being fragile and unreliable

Environment

• macOS (Darwin 25.2.0)
• Claude Code CLI