rel_path is backslash-separated on Windows: to_rel_path uses os.path.relpath and nothing normalises to POSIX form #214

rel_path is part of the API contract — test_rel_path_api_parity.py exists to hold it — and on Windows it is built from os.path.relpath, which returns backslash-separated paths.

The chain. _enrich_with_rel_path() (palinode/api/search_helpers.py) is what attaches rel_path to search, associative, dedup-suggest, orphan-repair and topic-coverage results. It calls to_rel_path() (palinode/core/path_guard.py), whose body is os.path.relpath(file_path, base). That is correct POSIX behaviour and correct Windows behaviour — it is just not the same string, and as_posix() appears nowhere in the package.

Seven test_rel_path_api_parity tests fail on native Windows in @Kaap10's 3.12 inventory and @kevin-lozada-santos's 3.11 inventory, both posted on #169. Whether all seven trace to this expression is for the fix to establish — that has not been verified, and it should not be assumed.

A separate, smaller instance in the same family. palinode/core/store.py derives a path for associative results with fp.replace(config.memory_dir + "/", "").lstrip("/") — a hardcoded separator. On Windows that replace never matches, so the value stays absolute. It feeds the result's category field, not rel_path, so the consequence is a wrong category rather than a broken contract. Worth fixing in the same pass; worth not conflating with the above.

The precedent is already in the tree. palinode/core/skip_dirs.py does rel_path.replace(os.sep, "/"). Someone solved this once, in one place, and it was never generalised.

What is wanted: rel_path renders in POSIX form on every platform, and a test that pins it so the next refactor cannot quietly undo it. Where the normalisation belongs — inside to_rel_path, or at the enrichment boundary — is a design call worth stating in the PR.

Not in scope: the rest of the Windows suite failures. Those are being carved separately.

Context: found by @Kaap10 and @kevin-lozada-santos during the native Windows runs on #169.

Reserved for @Kaap10, who claimed this slice on #169. GitHub currently rejects the direct assignment on this new issue; it is not open for another claim.