fix: rebuild API handler on profile switch with same provider/model

[roomote]

Description

This PR attempts to address Issue #9208 where switching to an API Profile that uses the same provider/model does not apply updated settings (e.g., reasoning level, headers, baseUrl, service tier).

Problem

When switching profiles via the dropdown or Settings view, if the provider and model remain the same, the active API client keeps using the previous settings instead of applying the new profile's configuration.

Solution

• Added a forceRebuild parameter to the updateTaskApiHandlerIfNeeded method
• When explicitly switching profiles via activateProviderProfile, always force rebuild the API handler
• This ensures all settings (baseUrl, headers, service tier, reasoning features, rate limits, etc.) are properly applied even when provider/model remain unchanged

Changes

• Modified src/core/webview/ClineProvider.ts:
  • Added forceRebuild parameter to updateTaskApiHandlerIfNeeded method
  • Updated activateProviderProfile to pass forceRebuild: true
  • Added clarifying comments about when to force rebuild
• Added test file src/core/webview/__tests__/ClineProvider.profile-switch.spec.ts with tests for the new behavior

Testing

• Existing tests pass without modification
• New test file covers the profile switching scenarios

Related

• Fixes [BUG] API Profile switch: same provider/model does not apply changed settings #9208
• Regression from PR fix: Model switch re-applies selected profile (sync task.apiConfiguration) (#9179) #9181

Feedback and guidance are welcome!

---

Important

Adds forceRebuild to updateTaskApiHandlerIfNeeded in ClineProvider.ts to ensure API handler rebuilds on profile switch, with tests added for verification.

• Behavior:
  • Adds forceRebuild parameter to updateTaskApiHandlerIfNeeded in ClineProvider.ts to ensure API handler rebuilds on profile switch.
  • Updates activateProviderProfile to use forceRebuild: true for explicit profile switches.
• Testing:
  • Adds ClineProvider.profile-switch.spec.ts to test profile switching scenarios, ensuring API handler rebuilds correctly.
  • Tests cover cases like reasoning level, service tier, and rate limit changes.
• Related:
  • Fixes issue [BUG] API Profile switch: same provider/model does not apply changed settings #9208.
  • Regression from PR fix: Model switch re-applies selected profile (sync task.apiConfiguration) (#9179) #9181.

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

[roomote]

Rooviewer   See task on Roo Cloud

Review Summary

I've completed a thorough review of this pull request. The implementation correctly addresses issue #9208 by ensuring that all API profile settings are applied when switching profiles, even when the provider and model remain the same.

Key Changes:

• Added forceRebuild parameter to updateTaskApiHandlerIfNeeded method
• Always forces API handler rebuild during explicit profile switches via activateProviderProfile
• Maintains existing behavior for upsertProviderProfile operations
• Comprehensive test coverage for the new functionality

Result: ✅ No issues found. The code is well-structured, the logic is sound, and the fix properly addresses the regression from PR #9181.

_{Mention @roomote in a comment to request specific changes to this pull request or fix all unresolved issues.}

[ellipsis-dev]

The test 'does not rebuild API handler when settings are updated through upsertProviderProfile' lacks an assertion to verify that buildApiHandler is not called. Consider adding an expect statement (e.g. checking that buildApiHandlerMock has not been called) to ensure non-forced updates do not trigger a rebuild.