feat: workspace-scoped mode-to-profile overrides

[roomote-v0]

Related GitHub Issue

Closes: #12227

Description

This PR attempts to address Issue #12227 by adding workspace-scoped mode-to-profile override mappings. Feedback and guidance are welcome.

Problem: Provider profiles and mode-to-profile mappings are stored globally, so switching between projects (workspaces) does not change which profile is active for a given mode. Users working on corporate projects with a corporate AI provider and personal projects with a different provider must manually switch profiles each time they change context.

Solution: A workspace-level override layer for mode-to-profile mappings, stored in context.workspaceState. When switching modes:

1. Check workspace-level workspaceModeApiConfigs first
2. Fall back to global modeApiConfigs if no workspace override exists
3. This is non-breaking -- new projects use global defaults as requested by the issue author

Key design decisions (based on @AseWhy feedback):

• Falls back to global settings when no project-specific config exists
• Integrated into the existing API config selector UI (workspace pin button in the profile dropdown)
• No export/import -- workspace profile mappings stay local to the machine

Files changed:

• packages/types/src/vscode-extension-host.ts -- Added workspaceModeApiConfigs to ExtensionState and new message types
• src/core/webview/ClineProvider.ts -- Updated handleModeSwitch() and getState() to check workspace overrides
• src/core/webview/webviewMessageHandler.ts -- Added handlers for set/clear workspace mode API config
• webview-ui/src/components/chat/ApiConfigSelector.tsx -- Added workspace profile pin toggle button
• webview-ui/src/components/chat/ChatTextArea.tsx -- Passes new props to ApiConfigSelector
• webview-ui/src/context/ExtensionStateContext.tsx -- Added default for workspaceModeApiConfigs
• webview-ui/src/i18n/locales/en/chat.json -- Added translation keys for new UI

Test Procedure

• Added webviewMessageHandler.workspaceModeApiConfig.spec.ts with 5 tests covering set, clear, preserve, and no-mode scenarios
• Ran existing ClineProvider.sticky-mode.spec.ts (33 tests), ClineProvider.sticky-profile.spec.ts, and ClineProvider.lockApiConfig.spec.ts -- all pass
• Lint and type checks pass across all packages

Pre-Submission Checklist

• Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
• Scope: My changes are focused on the linked issue (one major feature/fix per PR).
• Self-Review: I have performed a thorough self-review of my code.
• Testing: New and/or updated tests have been added to cover my changes.
• Documentation Impact: No documentation updates needed (workspace state is internal).
• Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Interactively review PR in Roo Code Cloud

[AseWhy]

@roomote

I noticed a contradiction in my last post: if the dropdown menu displays all modes, it creates a conflict regarding which profile should be used by default for a given mode. Ideally, the final implementation should be as follows: globally, modes do not change their behavior, but if a user has set their own profile for a mode in a specific project, then that profile should be used for that project. We could also add a “Project-specific profile usage” flag to the experimental features. In the profile settings, the dropdown does not display all modes, but only those not assigned to other providers

[roomote-v0]

Fixaroo   See task

Fixed the reported issues. Added a "Project-specific profile usage" experimental feature flag that gates all workspace profile override functionality. The workspace pin button now also shows a warning icon when the current mode is already pinned to a different profile. All local checks passed.

_{View commit | Revert commit}