fix: resolve macOS screenshot paths with narrow no-break space in load_image

[andrewtvuong]

Problem

macOS names screenshots with U+202F (narrow no-break space) before AM/PM.
That character is visually identical to an ordinary space, and copying such a
path into a prompt typically turns it into U+0020 — a genuinely different
filename on disk. load_image did a bare Path(image_path), so those paths
failed the exists() check and came back as "Image file not found".

for example: Screenshot 2026-08-28 at 8.55.11 PM

Fix

• _normalized_filename() — NFKC normalize, then collapse every whitespace
  character to a plain space.
• _resolve_image_path() — the exact path always wins. A fallback is accepted
  only when exactly one file in the requested parent normalizes to the same
  name, so it fails closed on ambiguity instead of guessing.
• load_image now reports the resolved path in the success message and
  return_value, and its metadata carries image_path (resolved),
  requested_image_path, and path_was_resolved.

Tests

New tests/tools/test_image_tools.py (there were no load_image tests before):
resolves the U+202F screenshot name, prefers an exact path over a normalized
sibling, fails closed on an ambiguous match, and handles a missing parent
directory. Unicode characters are written as \u202f / \u2009 escapes so they
survive copy-paste and stay visible in review.

Notes

• read_file and the other path-taking tools in file_operations.py have the
  same class of issue; this change deliberately does not touch them.