Resolve companion ranges across filename case differences

[imnasnainaec]

A LIFT folder written on Windows can spell its pair inconsistently — Dict.LIFT beside Dict.lift-ranges, or the reverse — and load fine there, because the filesystem folds case. On Linux the sibling candidate is built from the .lift's own name (_model.py:536), so it missed, the companion was skipped silently, and every range it defined went absent.

Not zip-specific: sil_lift.load("/data/Foo.LIFT") on Linux hits it with no archive involved, since parse_document never inspects the extension.

Approach

A candidate that matches no file exactly now falls back to one whose name folds onto it.

• Reached only after an exact miss, so a case-folding filesystem never enters the fallback and behaves exactly as before. The cost lands only where the lookup was already failing.
• One directory read per folder, cached across the candidate list, so a header with several range/@href entries doesn't re-scan.
• Both directions, since an exporter sloppy about one is sloppy about the other.
• Case and normalization form — casefold() over NFC, not lower(). FLEx writes the .lift in NFC and its companion in NFD within one export, and only APFS folds the two forms on its own; NTFS does not, so a mismatched pair fails to resolve on Windows as well.
• Only the final path component, so an href under a directory spelled in another case still does not resolve. The hrefs this serves are bare basenames or same-folder relatives.
• dangling-ranges-href decides existence the same way, so validation and loading agree on what is there.

Two things the fallback would otherwise have widened:

• A candidate that folds onto the .lift itself — a header href spelling Dict.lift beside a Dict.LIFT — is skipped. RangesFile.load rejects a <lift> root, so it would fail the whole load. Reachable on Windows before this PR, by an href naming the lexicon at all.
• A candidate that folds onto a companion already tracked is skipped. Path.resolve() leaves case alone on macOS, so one file reached under two spellings was loaded and tracked twice — and written twice by save().

Also in the area: the sibling candidate is built with with_name rather than with_suffix, which raised ValueError: Invalid suffix '-ranges' for a document loaded under a name with no extension. The two agree on every name that has one.

The tie-break

Where several names fold together, the first in code point order wins (Dict.LIFT-ranges ahead of Dict.lift-ranges). Arbitrary, but fixed — and fixed is the property that matters: directory order varies between filesystems and between runs, and a companion that resolved differently on consecutive reads would be worse than one that never resolved. The sort key is the name rather than the Path, since PurePath ordering is itself case-folded on Windows and would leave the choice to directory order there. Documented in _existing_file and asserted by a test.

Open to a different rule if you'd rather have one — e.g. preferring an exact case match on the stem — but I'd want it to stay deterministic.

Tests

Eight in test_ranges_folder.py: uppercase .lift, uppercase companion, an NFC/NFD filename mismatch, the tie-break, a negative case pinning that the fallback doesn't reach past a folder for a name that isn't in it, an extensionless .lift, an href folding onto the lexicon itself, and a case-variant companion that must not be reported dangling-ranges-href.

Only the tie-break needs both spellings to coexist, so it skips off Linux. The normalization test exercises the fallback on Windows and Linux alike (APFS resolves it without one), and the two self-reference tests are platform-independent.

python scripts/check.py green: 545 passed, 1 skipped (the tie-break, on Windows), 97% coverage.

Draft: opening for a read on the tie-break rule before marking ready.

🤖 Generated with Claude Code

---

Devin review: https://app.devin.ai/review/sillsdev/python-sil-lift/pull/19

---

This change is