Fix: Launch files from jar archives

[marko1olo]

Resolved / Related Issues

• Closes Bug: Cannot open files inside a .jar archive by double-clicking like in .zip archive #18533

Summary

• Launch files inside browsable archives through their streamed StorageFile representation instead of passing the virtual archive path to the Win32 shell path.
• Initialize LauncherOptions with the Files window handle for the archive-entry launch path, matching the nearby user-initiated launcher flows.
• Keep the existing Win32 fallback if the WinRT file launch fails.
• Leave normal filesystem files and the existing image-specific neighboring-files flow unchanged.

Why

Files inside archives such as .jar have virtual paths like archive.jar\path\File.class. Passing that path to the Win32 shell does not point at a real filesystem item, so double-clicking non-image files inside .jar archives can do nothing. ZipStorageFile.ToStorageFileAsync() already materializes archive entries as streamed StorageFile objects, which is the launch path used for archive images.

Steps used to test these changes

1. Ran git diff --check.
2. Restored the missing server assets with dotnet restore src\Files.App.Server\Files.App.Server.csproj -p:Platform=x64 --nologo.
3. Ran dotnet build src\Files.App\Files.App.csproj -c Debug -p:Platform=x64 --no-restore --nologo; the build reached the app XAML compilation stage, then failed with WMC9999 because the local XAML compiler package could not load Microsoft.UI.Xaml.Markup.Compiler.ErrorMessages.resources.
4. Compared the new archive-entry launch path with the existing image and app-picker launch paths in NavigationHelpers.OpenFile.

[Josh65-2201]

You should test your changes in Visual Studio https://files.community/docs/contributing/building-from-source what you put in the steps to test is not testing anything related to the change you have made

[Josh65-2201]

This doesn't show the open with prompt for files with no program associated

[marko1olo]

Good catch. I pushed 26df283 to cover that case as well.

The archive branch now keeps the direct LaunchFileAsync(storageItem, options) path for entries that already have an association, but if that returns false, it retries the same extracted StorageFile with LauncherOptions.DisplayApplicationPicker = true before falling back to the old Win32 launch path. That should make unassociated archive entries show the Windows app picker instead of trying to shell-launch the virtual archive.jar\entry path.

Suggested manual checks for this PR:

• Open a .jar in Files and double-click an entry whose extension has no default app. Expected: Windows "Open with" picker appears.
• Pick an app such as Notepad and verify the extracted archive entry opens.
• Re-check the original Bug: Cannot open files inside a .jar archive by double-clicking like in .zip archive #18533 scenario with a .class entry that has a default app. Expected: it still opens directly without forcing the picker.

Local checks:

• git diff --check passed.
• dotnet build src\Files.App\Files.App.csproj --no-restore -p:Configuration=Debug -p:Platform=x64 did not finish within 5 minutes in this checkout, so I stopped it and checked that no repo build processes were left running.