fix(file_tools): refresh staleness timestamp after writes

[teknium1]

Summary

Fixes false staleness warnings when the agent makes consecutive edits to the same file without re-reading between them.

The problem

After PR #4345 added staleness detection, the stored timestamp only updated on read_file calls. So a read → write → write sequence would warn on the second write: the first write changed the file's modification time, but the stored timestamp still reflected the original read. The agent's own edit triggered a "file was modified externally" warning.

The fix

_update_read_timestamp(path, task_id) is called after every successful write_file and patch. It refreshes the stored timestamp to match the file's current state, so the next write sees a matching timestamp and doesn't warn.

External edits still warn correctly — the update only fires for the task that performed the write. If a different task or external process modifies the file, the stored timestamp won't match.

Also renames the internal key from file_mtimes to read_timestamps for readability.

Files changed

File	Change
tools/file_tools.py	_update_read_timestamp() helper, wired into write_file_tool and patch_tool, rename file_mtimes → read_timestamps
tests/tools/test_file_staleness.py	Updated key name in helper unit tests

Test plan

• 64 existing file-tool tests pass
• E2E: 3 consecutive writes after one read → no warnings
• E2E: 2 consecutive patches after one read → no warnings
• E2E: external edit between writes → still warns correctly
• E2E: write → external edit → write → warns correctly