Fix ArgumentException crash when InfoPanel encounters paths with illegal characters

[Copilot]

This PR fixes a crash in QuickLook's InfoPanel when it encounters file paths containing illegal characters. The error manifested as:

System.ArgumentException: Illegal characters in path.
   at System.Security.Permissions.FileIOPermission.EmulateFileIOPermissionChecks(String fullPath)
   at System.Security.Permissions.FileIOPermission.QuickDemand(FileIOPermissionAccess access, String fullPath, Boolean checkForDuplicates, Boolean needFullPath)
   at System.IO.File.InternalGetLastWriteTimeUtc(String path, Boolean checkHost)
   at QuickLook.Plugin.InfoPanel.InfoPanel.DisplayInfo(String path)

Root Cause:
The InfoPanel.DisplayInfo() method was calling file system operations (File.GetLastWriteTime(), Path.GetFileName(), etc.) without defensive error handling. When QuickLook receives paths containing Windows-illegal characters like <>"|?*: or other invalid path constructs, these operations throw unhandled ArgumentException, causing the application to crash.

Solution:
Added comprehensive exception handling around all file system operations in InfoPanel.DisplayInfo():

• Path.GetFileName() - now handles ArgumentException and PathTooLongException
• File.GetLastWriteTime() - now handles ArgumentException, UnauthorizedAccessException, and PathTooLongException
• Background file operations - wrapped entire task with exception handling for the same exceptions

The fix provides graceful fallback behavior:

• Shows the full path when filename extraction fails
• Shows "Last modified: Unavailable" when date cannot be retrieved
• Shows "Size: Unavailable" when size calculation fails

Impact:

• Before: QuickLook would crash with unhandled exceptions when encountering problematic paths
• After: QuickLook gracefully handles invalid paths while maintaining full functionality for valid paths

This ensures QuickLook remains stable and usable even when dealing with edge cases involving unusual file paths.

Fixes #1734.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

@emako 👋 This repository doesn't have Copilot instructions. With Copilot instructions, I can understand the repository better, work faster and produce higher quality PRs.

I can generate a .github/copilot-instructions.md file for you automatically. Click here to open a pre-filled issue and assign it to me. I'll write the instructions, and then tag you for review.

[emako]

Path.GetFileName() - now handles ArgumentException and PathTooLongException
File.GetLastWriteTime() - now handles ArgumentException, UnauthorizedAccessException, and PathTooLongException
Background file operations - wrapped entire task with exception handling for the same exceptions

Why Path.GetFileName() and File.GetLastWriteTime() will call the ArgumentException?

@copilot

[Copilot]

Path.GetFileName() - now handles ArgumentException and PathTooLongException
File.GetLastWriteTime() - now handles ArgumentException, UnauthorizedAccessException, and PathTooLongException
Background ...

These .NET methods throw ArgumentException when they encounter invalid path characters:

Path.GetFileName() throws ArgumentException when:

• The path contains Windows-illegal characters: < > " | ? * :
• The path contains characters defined in Path.GetInvalidPathChars()

File.GetLastWriteTime() throws ArgumentException when:

• The path contains invalid characters (same as above)
• The path is malformed or contains invalid character sequences
• Internal Windows file system permission checks fail due to illegal characters

The original crash from issue #1734 showed this exact stack trace:

System.ArgumentException: Illegal characters in path.
   at System.IO.File.InternalGetLastWriteTimeUtc(String path, Boolean checkHost)

These exceptions occur because Windows file system APIs strictly validate path characters before performing operations. When QuickLook receives paths with problematic characters (e.g., from shell extensions or other sources), these methods fail immediately rather than gracefully handling the invalid input.

The defensive programming approach prevents crashes by catching these exceptions and providing fallback behavior instead of letting them bubble up unhandled.

[emako]

Unimportant exceptions, keep throwing errors