Fix WebView2 data directory failing on non-ASCII user profile paths

[hanos5]

Problem

When the Windows username contains non-ASCII characters (e.g. Japanese, Chinese, Korean), the IgniteView/WebView2 data directory path includes those characters. WebView2 cannot read or write to paths containing non-ASCII characters, causing the settings GUI to fail to launch with the error:

Microsoft Edge で、データ ディレクトリに対する読み取りと書き込みができません:
(Microsoft Edge cannot read and write to its data directory.)
C:\Users<non-ASCII username>\AppData\Local\IgniteViewApp\topnotify\DesktopNative\EBWebView

This is because AppIdentity.AppDataPath resolves to %LOCALAPPDATA%\IgniteViewApp\topnotify, which includes the user profile path. When DesktopWebWindow passes this path to WebView2 as its user data folder, WebView2 fails to handle the non-ASCII characters.

Solution

Introduced AsciiSafeAppIdentity, a subclass of AppIdentity that overrides AppDataPath to use CommonApplicationData (C:\ProgramData) instead of LocalApplicationData (C:\Users<username>\AppData\Local). The C:\ProgramData path is always ASCII-safe.
After ViteAppManager is initialized but before any WebWindow is created, the code checks whether the default AppDataPath contains non-ASCII characters. If it does, CurrentIdentity is replaced with the ASCII-safe variant.

Changes

• Program.cs: Added a non-ASCII path detection check after ViteAppManager initialization that replaces CurrentIdentity with AsciiSafeAppIdentity when needed
• Program.cs: Added AsciiSafeAppIdentity class that overrides AppDataPath to return C:\ProgramData<Developer><Name> instead of C:\Users<username>\AppData\Local<Developer><Name>

Impact

• Daemon (background process): No impact — the daemon does not use ViteAppManager or WebWindow
• TopNotify settings data: No impact — settings are stored separately via Settings.GetAppDataFolder() (%LOCALAPPDATA%\SamsidParty\TopNotify)
• Only affects WebView2 cache/session data: Redirected from %LOCALAPPDATA%\IgniteViewApp\topnotify\DesktopNative\ to C:\ProgramData\IgniteViewApp\topnotify\DesktopNative\
• Users with ASCII-only usernames: No change in behavior — the fallback is only activated when non-ASCII characters are detected

[hanos5]

Oh, I just found the Ascii.IsValid method. I think I can refactor the code to be much cleaner using this.

Ascii.IsValid Method
https://learn.microsoft.com/en-us/dotnet/api/system.text.ascii.isvalid?view=net-10.0

Please bear with me as I'm still learning the Git workflow.

[SamarthMP]

Hello, I appreciate your pull request, however this seems to be a problem that should be fixed within IgniteView not TopNotify.

I was unable to find any reports of non-ASCII characters tripping up webview2 outside of this one so I believe it's an issue in IgniteView string marshalling not with WebView2 or TopNotify.

I will try to fix it within IgniteView, thank you for the PR.

[hanos5]

Thank you for reviewing my PR and for your thoughtful feedback. Actually, this was my very first PR in the open-source community! I'm so excited and touched by your kind response. Open source is truly wonderful.

I’m a big fan of TopNotify and find it incredibly useful. Thank you for all your hard work. Please let me know if there’s anything else I can help with, such as testing. I’d be happy to assist!