Handle invalid CWD when creating file dialogs

[nikoskalogridis]

Summary

• fix a crash when SaveFileDialog is created while the process current working directory has been deleted/unmounted
• proactively validate and repair current directory before creating file dialogs
• retry SaveFileDialog construction after setting a safe fallback directory
• apply the same pre-check before OpenFileDialog creation

Root cause

On Linux/GTK, constructing Eto file dialogs may call Environment.CurrentDirectory (GetCwd). If the original working directory no longer exists, this throws System.IO.FileNotFoundException and the dialog never opens.

Changes

• NAPS2.Lib/EtoForms/EtoDialogHelper.cs
  • add EnsureCurrentDirectoryIsAccessible()
  • add SetSafeCurrentDirectory() with fallback order:
    1. Environment.SpecialFolder.UserProfile
    2. Path.GetTempPath()
  • add CreateSaveFileDialog() wrapper that catches FileNotFoundException, resets CWD, and retries
  • use CreateSaveFileDialog() in PromptToSavePdfOrImage, PromptToSavePdf, and PromptToSaveImage
  • call EnsureCurrentDirectoryIsAccessible() in PromptToImport

Validation

• file diagnostics for EtoDialogHelper.cs: clean
• full build not run in this environment (dotnet CLI unavailable)

Fixes #839