[Windows] Long paths (>260 chars) never hashed by save_manifest/_md5_file — files re-flagged as changed on every update

[Ns2384-star]

Version: graphifyy 0.9.5, Windows 11.

Problem

save_manifest / _md5_file use plain open(): files whose absolute path exceeds 260 chars are never hashed, so they are re-reported as changed on every update, forever (5 files on our corpus — deep, accented French folder names). cache._normalize_path already handles the \\?\ extended-length prefix for cache keys — but not for actual I/O.

Repro

Any file with an absolute path > 260 chars on a Windows box without the LongPathsEnabled registry opt-in: _md5_file fails/skips, the manifest entry never stabilizes, detect_incremental flags the file as changed on every run.

Proposal

On win32, prefix \\?\ before every open()/stat() in detect.py (hashing + word count), same normalization cache.py already does.

Related: #629 (closed — fixed the same class of problem for the semantic cache lookup).

[safishamsi]

Fixed in f917494 (on v8, ships in 0.9.7). Thanks, and good catch that cache._normalize_path handled this for keys but not for I/O.

Added a _os_path helper that prefixes long absolute paths with \\?\ on win32 (UNC paths get \\?\UNC\...), applied to the change-detection I/O in detect.py: _md5_file, _stat_and_hash, detect_incremental's stat, count_words, and the new office-sidecar mtime check. It's the mirror of _normalize_path (which strips the prefix for stable keys). No-op on other platforms. Your 5 deep/accented files should now hash and stabilize instead of re-flagging every run.

Note: I scoped this to the change-detection paths you identified; the office/PDF parser libraries open paths internally and would need the same treatment for conversion of >260-char sources, but that's a separate symptom (conversion failure, not manifest churn) — happy to take a follow-up if you hit it.