Fix llama.cpp loading for Unicode Windows profiles

[Imagineer99]

Summary

• keep llama.cpp model loading available for Windows users whose profile path contains non-ASCII characters
• omit only the optional --slot-save-path argument on affected native Windows paths
• preserve slot persistence unchanged for ASCII Windows paths and every non-Windows platform

Root cause

llama.cpp currently validates --slot-save-path through a narrow std::filesystem::path construction on Windows. An existing UTF-8 path such as C:\Users\Егор\.unsloth\studio\cache\llama-slots is therefore reported as “not a directory”, and llama-server exits before loading the model.

Slot persistence is an optional idle-unload optimization. This change degrades only that optimization on the affected path instead of preventing the model from loading at all. The fallback can be removed once the managed llama.cpp runtime includes an upstream UTF-8-safe directory check.

Before / after

The Playwright probe drives the real Studio model picker and asserts that the before/after /api/inference/load request bodies are identical. The UI response is deterministic and stubbed; the command-level behavior is covered separately by the backend A/B regression test and direct llama-server reproduction.

Validation

• 116 passed — test_llama_extra_args_platforms.py and test_llama_cpp_slot_resume.py
• 4 passed — focused Unicode-path tests
• 3 passed — focused slot capability/server argument tests
• Ruff passed for both changed files
• git diff --check passed
• direct Windows llama-server A/B: ASCII directory accepted; existing Unicode directory rejected with the reporter's error
• Playwright A/B: exact error visible before, loaded state visible after, request payloads identical

One unrelated test selection could not collect locally because the compatibility environment does not include python-multipart.