Compare a pin file's tree by name, not by the platform's path separator

[aksOps]

Main went red on fmt, clippy, test (windows-latest) immediately after #53. Linux, macOS, MSRV, the corpus gates and CodeQL were all green; only Windows failed, on a_pin_file_compared_against_another_tree_is_refused.

What was actually wrong

run_pin decided whether a pin file was taken over the tree being scanned with

Path::new(&pinned.corpus) != path

but a pin header can only ever hold a /-separated path — the writer normalises, deliberately, because the pin format has no escapes and a Windows \ would write a header no later run could read back. So on Windows the stored side reads C:/x while the scanned side is C:\x, and whether a pin file matched its own tree was left to the platform's path semantics rather than decided by the tree.

The refusal message had the same split: it printed pinned.corpus as stored and path.display() as scanned, so the two paths appeared with different separators and the message read as though the separator were the difference.

Both sides are now normalised once, before the comparison and in the message.

Why CI had not caught it

The failing assertion sits before the test's positive half — "and the tree it does name still passes, so the check is not simply refusing everything". Windows panicked on the message assertion and never reached it, so the case that matters most on Windows — a pin file matching the tree it names — has never been exercised there. With this fix the Windows job reaches it for the first time.

This is the same class as #43, where write_baseline recorded a Windows path with \ and parse_baseline refused escapes by design: the writer normalises and something downstream did not.

Verified

• cargo fmt --all --check rc 0
• cargo clippy --all-targets -- -D warnings rc 0
• cargo test --test edge_pins rc 0 — 35 passed, 0 failed

The Windows job is the real proof and runs on this PR.

🤖 Generated with Claude Code

https://claude.ai/code/session_01SF9KvRKVzA2vEYqtFq23zm