fix: respect custom storage path for global custom modes

[roomote]

Description

This PR fixes an issue where the custom storage path setting was not being respected when loading global custom modes. The extension would always look for custom modes in the default storage location, even when a custom path was configured.

Problem

When users configured a custom storage path via the roo-cline.customStoragePath setting, the extension would:

• Correctly save new modes to the custom location
• But fail to load them because it was looking in the default location

Solution

Updated ensureSettingsDirectoryExists() to use getSettingsDirectoryPath() which properly respects the custom storage path setting. This ensures that all operations (read/write) for global settings use the same path resolution logic.

Changes Made

1. src/utils/globalContext.ts: Updated ensureSettingsDirectoryExists() to use getSettingsDirectoryPath() instead of hardcoding the path
2. src/core/prompts/instructions/create-mode.ts: Updated to use getSettingsDirectoryPath() for displaying the correct path in instructions
3. src/utils/migrateSettings.ts: Updated to use getSettingsDirectoryPath() for consistency

Testing

• ✅ All existing tests pass
• ✅ Manually tested with custom storage path configured
• ✅ Verified that custom modes are now loaded from the custom storage location

Impact

This fix ensures that:

• CustomModesManager.getCustomModesFilePath() correctly uses the custom storage path
• SimpleInstaller.getModeFilePath() correctly uses the custom storage path
• All global settings operations are consistent in their path resolution

Fixes #8122

---

Important

Fixes custom storage path handling for global custom modes by updating path resolution logic in key functions.

• Behavior:
  • Fixes issue where custom storage path was ignored for global custom modes.
  • Updates ensureSettingsDirectoryExists() in globalContext.ts to use getSettingsDirectoryPath().
  • Updates createModeInstructions() in create-mode.ts to use getStorageBasePath().
  • Updates migrateSettings() in migrateSettings.ts to use getStorageBasePath().
• Functions:
  • getStorageBasePath() in storage.ts now optionally avoids creating directories for path resolution.
  • getSettingsDirectoryPath() in storage.ts ensures directory creation.
• Testing:
  • All existing tests pass.
  • Manually tested with custom storage path configured.
  • Verified custom modes load from custom storage location.

^{This description was created by for 604a606. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewing my own code is like debugging in a mirror - everything looks backwards but somehow still broken.

[roomote]

Is this comment on line 11 accurate? Since getSettingsDirectoryPath already creates the directory (as seen in storage.ts line 66), could we simplify this function to just be a direct pass-through? Something like:

Suggested change

	// getSettingsDirectoryPath already creates the directory, so we just return the path
	export async function ensureSettingsDirectoryExists(context: ExtensionContext): Promise<string> {
	return getSettingsDirectoryPath(context.globalStorageUri.fsPath)
	}

This would eliminate the redundant variable assignment and make the code more concise.

[roomote]

Minor observation: The original function had explicit mkdir with error handling, but now we're delegating all error handling to getSettingsDirectoryPath. Is this intentional? The errors will still bubble up, but we lose the ability to add any function-specific error context here if needed in the future.

[roomote]

Good consistency update! This ensures the help text shows the correct path when a custom storage location is configured. Users will see the actual path where their modes will be saved.