Fix: one case-duplicate path collapses the entire unmapped page to per-file units

[sebclark]

The bug

If a library contains two catalogued files whose paths differ only by casing (easily produced by sync tools or case-insensitive mounts renaming a folder's case, which leaves both spellings behind), BookImportUnitGroupingService.BuildUnmappedUnits throws:

System.ArgumentException: An item with the same key has already been added. Key: <path>

because poolFiles.ToDictionary(file => file.Path, StringComparer.OrdinalIgnoreCase) requires case-insensitively-unique paths. The controller's safety net then degrades the entire unmapped page to per-file units — grouping, group selection, and the group counts all silently break for every file, not just the offending pair (observed live: the header pill showing a book-group count within a few dozen of the raw file count on a large library, with folder grouping gone).

Fix

Build the lookup with GroupBy(..., OrdinalIgnoreCase) keeping the first file per case-folded path, so a handful of degenerate rows can't take down grouping for everyone. The duplicate file itself simply falls back to its own per-file unit, which is the existing behaviour for anything outside a built unit.

Tests

• case_only_duplicate_paths_should_not_break_unit_grouping — written first against unpatched develop, where it fails with the exact ArgumentException above; passes with the fix
• Full MediaFiles + grouping suite: 704/704 passing
• Production soak: running on my instance against the real pathological data (five case-duplicate folder pairs); grouping restored and no degradation warnings since