Regression: `Semantics::file_to_module_def` sometimes returns no result on Windows DOS device paths

When using rust-analyzer as a library for analysis, rust analyzer has started to flakily misbehave on Windows paths. This was first seen in https://github.com/github/codeql/pull/18443, but I've managed to reduce the issue in this repository.

What I do is to load a project contained in a workspace using ra_ap_load-cargo::load_workspace_at with default settings, then starting from a path to a module in the crate do some dance to map it to a file ID in the VFS (going from PathBuf to Utf8PathBuf, then to AbsPathBuf, then to VfsPath), and then call Semantics::file_to_module_def. This should work, but in some cases fails on Windows if the initial path is a DOS device path (i.e. //?/ prefixed paths), which is what PathBuf::canonicalize will return on Windows.

This can be seen running this workflow.

Some things I've noticed

• everything works on Linux
• this used to work in version 0.0.248
• failure is flaky, but quite frequent
• a workaround is to use dunce for canonicalization, but that will not work for long paths (more than 256 chars in general)

rust-analyzer version: 0.0.257

rustc version: 1.83

editor or extension: none (using rust-anlyzer as a library)

relevant settings: (eg. client settings, or environment variables like CARGO, RUSTC, RUSTUP_HOME or CARGO_HOME)

repository link (if public, optional): https://github.com/redsun82/rust-analyzer-windows-issue

code snippet to reproduce: see https://github.com/redsun82/rust-analyzer-windows-issue/blob/main/tests/load.rs, failure can be seen on windows running cargo test multiple times

Start with tests/load.rs in the linked reproduction and run its cargo test workflow repeatedly on Windows using a DOS device path. Trace the PathBuf to Utf8PathBuf to AbsPathBuf to VfsPath conversion before Semantics::file_to_module_def. Done means the module definition is found reliably for the reported Windows paths without regressing Linux behavior.