Move the fix into resolveCaseInsensitive

[utkarshdalal]

This builds on your PR but moves the actual fix to where the bug is: FileUtils.resolveCaseInsensitive.

The root cause isn't Epic-specific. resolveCaseInsensitive gave up case-insensitive matching for the entire rest of the path the moment listFiles() returned null:

} else {
    // append remaining segments verbatim
    for (j in i until segments.size) current = File(current, segments[j])
    return current
}

On-device the app can't list /, /data, /data/user, etc. (they return null), so anchored at File("/") the walk bailed on the very first segment and appended everything — including locallow — verbatim, never reaching AppData/. That's why it passed your unit tests but failed on a real device: on a dev box you can list from /, so the walk descends all the way down and matches LocalLow.

Fix is to descend with the literal segment and keep going instead of bailing, resuming case-insensitive matching at any level we can actually read. With that, the original one-liner works as-is, GOG saves get the same robustness for free, and resolveAbsolutePathCaseInsensitive is no longer needed.

I kept canonicalizeAppDataSegments since it's still useful for getting the casing right when creating a save dir that doesn't exist yet.

Tests: replaced the resolveAbsolutePathCaseInsensitive test with one that exercises the real resolveCaseInsensitive(File("/"), ...) path, plus a regression test that an unmatched/unlistable intermediate segment no longer aborts matching beneath it. :app:testModernDebugUnitTest passes.

[utkarshdalal]

I made a PR to your branch that puts the change into CaseInsensitiveFileSystem - can you check and try it?