bad-argument-type false positive for multiple venvs in one check

### Describe the Bug

I ran into an `bad-argument-type` false positive on a large monorepo I work on. After a lot of probing, I had claude try to summarize the situation as succinctly as possible. Happy to answer any questions or provide clarification. I think claude did a decent job but want to be upfront that I did not specifically write the following bug description.

When a single `pyrefly check` invocation transitively reaches files that live under different `pyproject.toml` files (each with their own `.venv`), and those venvs both have a shared dependency installed at independent on-disk paths, pyrefly creates two `Class` objects for the same nominal type and treats them as unrelated. The user-visible symptom is an error of the form `Argument X is not assignable to parameter Y with type X` — identical type printed on both sides.

`mypy` and `pyright` against the same sources report zero errors.

This appears to be the next-step generalization of the case already documented in `crates/pyrefly_python/src/module_path.rs:265–267` (the docstring on `ModulePath::to_key_eq`):

> *For nominal types, we consider FileSystem and Memory to be equal. This is important in the IDE when an in-memory module reaches its own nominal type through a cycle, where we end up with two classes, one from the Memory path and one from the FileSystem path.*

…and addressed by commit `ed6224fd4` ("Treat InMemory and FileSystem module paths as equivalent for class def equality"). The repro below shows the same shape — same nominal module, two on-disk paths backing it, two `Class` objects, identity mismatch — but with two `FileSystem` paths instead of `FileSystem`/`Memory`.

### Sandbox Link

_No response_

### (Only applicable for extension issues) IDE Information

_No response_