fix(runtime): normalize Windows workspace paths

[SulimanAbdulrazzaq]

Summary

• Normalize Windows extended-length (\\?\) and regular path representations before enforcing workspace boundaries.
• Cover DOS and UNC prefix variants with regression tests.

Fixes #3278

Anti-slop triage

• Classification: actionable-fix
• Evidence: Reproduction and Windows path-prefix analysis in grep_search: spurious "escapes workspace boundary" on first run in a directory with no .claw/ (Windows) #3278; no matching active PR found.
• Non-destructive review result: merge candidate

Verification

• cargo fmt --manifest-path rust/Cargo.toml --all -- --check
• git diff --check
• cargo +stable-x86_64-pc-windows-gnu check --manifest-path rust/Cargo.toml --target x86_64-pc-windows-gnu -p runtime
• cargo +stable-x86_64-pc-windows-gnu clippy --manifest-path rust/Cargo.toml --target x86_64-pc-windows-gnu -p runtime --lib (completed with existing warnings outside this change)
• Runtime unit tests: the repository's Windows-target test build currently fails in pre-existing Unix-only std::os::unix::fs::PermissionsExt tests; the default MSVC toolchain also lacks link.exe in this environment.
• No secrets, tokens, private logs, or unrelated generated files are included.

Resolution gate

• This PR resolves grep_search: spurious "escapes workspace boundary" on first run in a directory with no .claw/ (Windows) #3278 with a focused path-comparison fix and regression coverage.

[1716775457damn]

Nice catch on the \\?\ prefix. One edge case worth confirming: does this also handle \\.\ device namespace paths (e.g. \\.\C:\foo)? Those can appear when calling GetFullPathName without the FILE_FLAG_OPEN_REPARSE_POINT flag on symlinks/junctions. Also, short (8.3) name normalization via GetLongPathName may be relevant for paths coming from legacy tooling.

[1716775457damn]

Confirmed - I've hit this on Windows too: some APIs hand back paths with the \?\ prefix while the workspace root is stored without it, so the boundary check falsely reports escapes. Normalizing both forms before comparison is the right approach, and covering DOS/UNC variants in regression tests is good. One thing worth checking: Windows path comparisons should also be case-insensitive - make sure the normalized comparison doesn't regress on case differences (e.g. C:\Users vs c:\users).