Disk-modification staleness checks for file reads and writes are now properly async

What

• The Read tool's guard that decides whether a previously-read file has since changed on disk was synchronous and compared in-memory timestamps; it's now async and calls a new disk mtime lookup (via an ioPath).
• The Edit/Write external-modification guard is now only invoked when both the file handle and its read content are non-null, is properly awaited instead of being fired without waiting, and also passes a new ioPath field; the returned state now includes a remedy: { kind: "staged_for_review", path: ... } field.

Why

Without awaiting these checks, a write or edit could proceed before Claude Code actually knew whether the file had changed on disk, risking silently overwriting external changes.