Gracefully handle cross-OS path conflicts during restore

[woutervanranst]

Summary

Commit 11fe5668026c4e62837bd688578dd158679c7d60 removed the archive-time hard requirement that rejected path collisions up front. That improves archive portability, but it leaves a follow-up gap on restore: a snapshot can now legitimately contain paths that cannot be materialized cleanly on the current OS/filesystem.

Problem

Restore should not rely on every archived path being directly writable on every target OS.

Examples:

• Case-only distinct paths archived on a case-sensitive filesystem, then restored onto a case-insensitive filesystem
• Windows-invalid names or path forms restored on Windows (CON, NUL, trailing dots/spaces, etc.)
• Other filesystem-specific path conflicts where two archived entries map to the same effective destination path

Today this looks like a place where restore can still fail awkwardly or behave unclearly after the archive-side validator was removed.

Enhancement

Add a restore-side strategy for cross-OS compatibility that degrades gracefully instead of failing the whole restore.

Possible direction:

• Detect destination-path conflicts before writing files
• Restore all non-conflicting files normally
• Skip or quarantine conflicting entries with explicit reporting
• Surface a clear summary of skipped/conflicting paths in the restore result / logs

Acceptance Direction

• Restoring a snapshot with cross-OS-incompatible paths should not abort the entire restore when unaffected files can still be restored
• The user should get a clear explanation of which paths were skipped or conflicted and why
• Behavior should be covered by integration tests for representative cross-OS collision cases

Context

This is a follow-up to the archive-side change in 11fe5668026c4e62837bd688578dd158679c7d60.

[woutervanranst]

related:

That looks fine, but on Windows File.Exists is case-insensitive, so this:
shared.txt
shared.txt.POINTER.ARIUS
makes File.Exists("shared.txt.pointer.arius") return true even though Arius says uppercase suffix is not a pointer path.

[woutervanranst]

related:

Failing test:

• Enumerate_UppercasePointerSuffix_IsTreatedAsComparablePointerDuringEnumeration
  Failure:
  pairs[0].Pointer!.Path
  should be
  photos/vacation.jpg.POINTER.ARIUS
  but was
  photos/vacation.jpg.pointer.arius
  So your reverted LocalFileEnumerator still passes the global pointer helper semantics, but it fails the archive enumerator expectation that Pointer.Path preserves the actual discovered casing instead of canonicalizing to lowercase.

On Windows

• vacation.jpg.POINTER.ARIUS is recognized as a pointer path because of OrdinalIgnoreCase
• ToBinaryPath() maps it to vacation.jpg
• FileExists("vacation.jpg") is true
• so the pointer file is skipped as a separate entry
• when enumerating the binary vacation.jpg, it probes vacation.jpg.pointer.arius
• FileExists(...) is also true on Windows because the FS is case-insensitive
• result:
  • one FilePair
  • RelativePath = vacation.jpg
  • Pointer.Path = vacation.jpg.pointer.arius (canonicalized, not the actual on-disk uppercase casing)
    On Linux
• vacation.jpg.POINTER.ARIUS is also recognized as a pointer path because of OrdinalIgnoreCase
• ToBinaryPath() maps it to vacation.jpg
• FileExists("vacation.jpg") is true
• so the pointer file is skipped as a separate entry
• when enumerating the binary vacation.jpg, it probes vacation.jpg.pointer.arius
• on Linux that exact lowercase file does not exist if only the uppercase one exists
• result:
  • one FilePair
  • RelativePath = vacation.jpg
  • Pointer = null
    So today the difference is:
    Windows: binary + pointer
    Linux: binary only
    for the exact same directory contents when the pointer file exists with uppercase suffix only.
    That is the cross-OS inconsistency.