fix: normalize file paths in read tool output

[scarf005]

Problem

When the read tool displays file paths outside the worktree, it shows confusing relative paths like:

read ../../../../../../home/scarf/foo/bar/baz.ts

This is hard to understand and makes the output noisy.

Solution

Modify the read tool to check if a file is within the worktree before deciding how to display the path:

• Inside worktree: Show relative path (e.g., src/tool/read.ts)
• Outside worktree: Show absolute path (e.g., /home/user/other/file.ts)

This improves UX by showing clean, understandable paths.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Potential path traversal in file read/write tools #11703: Potential path traversal in file read/write tools (also involves read tool path normalization)
• Path traversal vulnerability via symlinks and cross-drive paths #8313: Path traversal vulnerability via symlinks and cross-drive paths (related to path normalization and symlink resolution)
• Worktrees created from bare repos are not recognized #10643: Worktrees created from bare repos are not recognized (involves worktree path resolution)
• Patch tool should fail fast on paths outside workspace #11113: Patch tool should fail fast on paths outside workspace (similar logic of determining workspace/worktree boundaries)

Additionally, these related issues suggest ongoing work in path handling across the codebase:

• External directory permission does not work on Windows #11042: External directory permission does not work on Windows (cross-platform path normalization)
• TUI sends absolute local paths causing ENOENT on server side #4686: TUI sends absolute local paths causing ENOENT on server side (path normalization between contexts)

Feel free to ignore if none of these address your specific case.