fix: ensure all diagnostic paths in baseline are relative

[yeetypete]

Summary

Fixes #2547

When pyrefly writes baseline.json, files located outside the current working directory (e.g. referenced via ../../libs/foo in search-path) were stored with absolute paths. This breaks baseline matching in CI where the checkout path differs from a local dev environment.

Changes:

• Internally BaselineKey now always contains absolute paths. This decouples key comparison from the path format (relative or absolute) in the baseline file on disk.
• Added tests to make sure baseline parsing is backwards compatible with old absolute path format.
• Paths in baseline are always stored with forward slashes for cross-platform compatibility of a baseline file, i.e. if some devs use windows and some linux.

Test Plan

• Ran all tests manually.
• Tested manually to make sure pyrefly check still works with an older absolute path baseline, and that regenerating the baseline creates one with relative paths. Then tested to make sure pyrefly check works on the new baseline.

[yeetypete]

oh dear, looks like I have to fix some windows path stuff...

Edit: I changed a bit more than I'd have liked to to accomodate Windows paths. I think it makes sense that the baseline files are cross platform so I decided to always store the paths in the baseline in unix format. lmk if this is too much of a drastic change.

[Arths17]

Hey @yeetypete, thanks for working on this! Making the baseline paths relative is definitely a win for CI consistency.

Full disclosure: I’m not a maintainer or regular contributor, just a developer looking through PRs and giving feedback as I get to know the codebase.

I noticed the mypy_primer (7) check is failing, but you can probably ignore that for now. There’s been a lot of talk on the Discord about this being a known infrastructure issue affecting several PRs, so it doesn't seem related to your changes in relativize.rs.

One technical question: for the Relativize() trait, how does it handle cases where files are on different drive letters on Windows (e.g., project on C: but a library on D:)? Since a relative path can't cross drives, I'm curious if the logic falls back to an absolute path or if that's handled elsewhere.

[visr]

I think it makes sense that the baseline files are cross platform so I decided to always store the paths in the baseline in unix format.

Thanks for this, I was just about to file an issue, when I noticed that my Windows-generated baseline.json did not seem to apply at all on our Linux CI for this reason.

[yeetypete]

@Arths17 yes, at the moment paths pointing to a different drive letter will fall back to being absolute. I don't know a good way around this but I also don't know why one would want to distribute code across different drive letters. That sounds very fragile.

Alternatively we can choose to fail hard here and prevent such behavior, but idk if thats worth doing.