Fix relay compiler path issues for Windows

[christiansany]

Fixes #5347

The bug

On Windows, the Relay LSP breaks for every graphql tagged literal starting with relay-compiler 21.0.0 (20.0.0 works). The schema can't be resolved and IDE features (hover, autocomplete, diagnostics) silently stop working. The LSP log shows:

Unable to convert URI to file path: Uri { scheme: Some("file"), … path: "/c%3A/Development/repo-relay-compiler-bug/src/something.graphql" }

The give-away is %3A (a URL-encoded :) and the leading slash before the drive letter: the compiler is treating the raw URI path as a filesystem path instead of decoding it into c:\Development\….

macOS/Linux are unaffected because their URI paths (/Users/…) need no decoding and have no drive letter.

Root cause

This is a regression from 6098dee ("Update from lsp-types 0.94 to 0.97"), which migrated relay-lsp from lsp_types::Url (backed by the url crate) to lsp_types::Uri (backed by fluent-uri).

Url::to_file_path() used to do two Windows-critical things that the new API does not:

1. Percent-decode the path (%3A → :).
2. Normalize the Windows drive letter by stripping the leading / (/C:/… → C:\…).

The migration replaced those calls with a naïve Path::new(uri.path().as_str()), and Uri::path() returns the raw, still-percent-encoded path. So on Windows the path stays /c%3A/…, which is:

• not absolute → get_file_group_from_uri returns the "Unable to convert URI to file path" error above (schema resolution fails), and
• not starts_with(root_dir) → is_file_uri_in_dir returns false, so the LSP treats the file as outside the project and ignores its didOpen/didChange entirely (hover/autocomplete break).

The reverse direction (path → URI) was already re-fixed in #5285 (path_to_file_uri), but the mirror URI → path conversion was never restored — that's the remaining gap.

The fix

Added a uri_to_file_path() helper in relay-lsp/src/utils.rs that restores the old Url::to_file_path() behavior:

• rejects non-file URIs (returns None),
• percent-decodes the path via the percent-encoding crate (already a dependency), and
• strips the leading / only when a Windows drive-letter component (C:, C:/, C:\) follows — Unix paths pass through verbatim.

Both broken call sites now route through it:

• is_file_uri_in_dir → uri_to_file_path(uri).is_some_and(|p| p.starts_with(root_dir))
• get_file_group_from_uri → converts via uri_to_file_path, keeping the existing is_absolute() guard.

This is behaviorally equivalent to what Url::to_file_path() produced in 20.0.0 (same case-preserving output; Rust already compares Windows drive prefixes case-insensitively, and the starts_with comparison itself is unchanged from before the regression).

Tests

Added a #[cfg(test)] mod tests in utils.rs (matching the existing inline-unit-test convention used across the compiler, e.g. file_categorizer.rs) covering:

• Unix path passthrough,
• the percent-encoded Windows drive letter — the exact file:///c%3A/… URI from the issue → c:/…,
• an unencoded file:///C:/… drive letter,
• percent-decoding of spaces (%20),
• non-file schemes → None,
• a round-trip through path_to_file_uri (the reverse direction), and
• the drive-letter detection predicate.

Testing

• We're verified this fix on multiple windows machines, including the original reporter's environment, and confirmed that the LSP now works correctly.
• cargo test -p relay-lsp — all new tests pass, existing tests green.
• cargo fmt / cargo check clean per CONTRIBUTING.md.
• The change is confined to relay-lsp/src/utils.rs; no API, schema, or compiler-CLI changes.