[Bug] Settings write fails ("Failed to save settings") due to case-sensitivity mismatch in Windows installation path

[AnyaForger114514]

Bug Description

When using DSH Desktop version 0.2.1-rc.2 on Windows, attempting to change settings (models, themes, preferences) in the UI fails and shows "Failed to save settings, please retry" (未能保存设置，请重试).

After deep debugging (with the help of an AI agent), we found the root cause is module duplication caused by case-sensitivity inconsistencies in the Windows installation path.

Environment

• OS: Windows 11 (win32 x64)
• DSH Version: @deepseek-ai/dsh-desktop 0.2.1-rc.2
• Installation Path: E:\ruanjian\DSH (Notice the uppercase DSH)

Root Cause Analysis

1. bootstrapIncludes is a module-level WeakMap inside dsh-app-boot.
2. The Electron main process gets the app path via app.getAppPath(), which returns a lowercase string (E:/ruanjian/dsh/...).
3. The actual directory on disk is uppercase (E:\ruanjian\DSH), and Node/realpath normalizes it to uppercase.
4. ESM caches modules by URL string. Therefore, the same file is imported twice with different spellings (dsh vs DSH), creating two separate module instances (and two separate WeakMaps).
5. bootstrapIncludes.set() is called in instance A, but the config-editor / hmr modules query bootstrapIncludes.get() from instance B.
6. Result: The map is empty, throwing dsh: profile reload requires the root Include entry, and all settings/mutate RPCs fail silently with a UI rollback.

Proof / Control Experiment

Launch Argument	Actual Disk Name	Result
Host argv Uppercase	Uppercase DSH	settings/update ok=true
Host argv Lowercase	Uppercase DSH	settings/update rejected (Module split)
Host argv Lowercase	Lowercase dsh (Renamed)	settings/update ok=true

Workaround (Temporary Fix)

1. Fully close all DSH processes.
2. Rename the installation folder to match the lowercase spelling expected by the app (e.g., E:\ruanjian\DSH -> E:\ruanjian\dsh).
3. Update environment variables and shortcuts to point to the lowercase path.
4. Launch again. Settings can now be saved successfully.

Suggested Fix

Consider normalizing the path and resolving symlinks before caching in dsh-app-boot:

• Use fs.realpathSync.native() or path.normalize() to force consistency before ESM resolution.
• Or, store bootstrapIncludes in a global symbol (e.g., Symbol.for('dsh.bootstrapIncludes')) on globalThis to prevent module instance duplication.

Note: This issue was discovered and debugged by a user. Huge thanks to the community for the help!