in_memory_filesystem_shim test fails on Windows: in-memory keys are stored with / and looked up with \

Start in src/shim_filesystem.rs with add_in_memory_file, get_in_memory_key, and the in_memory_filesystem_shim test. Run cargo test --release --lib 'shim_filesystem::tests::in_memory_filesystem_shim' -- --exact on Windows and inspect how inserted and looked-up paths are spelled. Done means the in-memory lookup uses a consistent key representation and the test passes on Windows without changing the zip feature behavior.

On Windows, shim_filesystem::tests::in_memory_filesystem_shim fails on main (0.7.6-rc.4) at the first assertion:

thread 'shim_filesystem::tests::in_memory_filesystem_shim' panicked at src\shim_filesystem.rs:549:9:
assertion failed: is_file_shim(file_path)

Reproduce with cargo test --release --lib 'shim_filesystem::tests::in_memory_filesystem_shim' -- --exact. It fails in isolation, so it is not interference from another test. It does not show up under --features include-zip, because the test module is gated on not(any(target_family = "wasm", feature = "include-zip")).

Cause

The in-memory map is written with one key spelling and read with another.

add_in_memory_file inserts the path exactly as the caller wrote it:

files.get_or_insert_with(HashMap::new).insert(path.to_string(), content.to_string());

Every lookup goes through get_in_memory_key, which runs the path through canonicalize_shim. That function rebuilds the path component by component with PathBuf::push, and on Windows push joins with a backslash:

inserted:  virtual/rules/Languages/en/test_Rules.yaml
looked up: virtual\rules\Languages\en\test_Rules.yaml
match: false

So the key never matches and is_file_shim falls through to path.is_file(), which is false for a path that only exists in the map.

On Linux and macOS push joins with /, the two strings are equal, and the test passes. That is presumably why CI has not caught it.

Suggested fix

Have add_in_memory_file store get_in_memory_key(Path::new(path)) rather than the raw string, so writes and reads agree on one spelling. The zip-backed branch already solves the same problem with canonicalize_path_separators, so normalising to / in get_in_memory_key would work too and would keep the two branches consistent.

Happy to send a patch if you would like one. Found while working on #816.