[BUG] Persistence of Compatible OpenAI API endpoint

[LADLABS]

Problem (one or two sentences)

I use a compatible OpenAI endpoint, I configure the endpoint,key,model name and use it fine. but when i switch to an other provider (gemini for example) use it, when I return to the compatible OpenAI provider the configuration is not saved (I have to configure it each time I use another provider)

Context (who is affected and when)

Happens when switching between provider

Reproduction steps

1. Confifure a compatible OpenAI provider
   2)Use it
   3)Switch to an other provider (gemini for example)
   4)use it
2. Return to the compatible OpenAI provider
   -> the initial configuration has disapear.

Expected result

THe configuration of the compatible OpenAI provider should be saved and keep

Actual result

THe compatible OpenAI configuration is not saved

Variations tried (optional)

No response

App Version

3.47.3

API Provider (optional)

None

Model Used (optional)

No response

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause

When a user saves a provider profile after switching the apiProvider dropdown (e.g., from "openai" to "gemini"), the ProviderSettingsManager.saveConfig() method at src/core/config/ProviderSettingsManager.ts:362-364 uses discriminatedProviderSettingsWithIdSchema.parse(config) to filter the incoming settings. This discriminated union schema strips out all fields that don't belong to the newly selected provider. For example, switching from "openai" (OpenAI Compatible) to "gemini" strips openAiBaseUrl, openAiApiKey, openAiModelId, etc.

The stored profile then only contains settings for the currently active provider. When the user switches back to "openai", those settings are gone because they were removed from storage.

Proposed Fix

Modify ProviderSettingsManager.saveConfig() to preserve settings from other providers when updating an existing profile:

1. In saveConfig() (src/core/config/ProviderSettingsManager.ts): Instead of completely replacing the stored config with only the discriminated-filtered result, merge the new filtered settings with the existing stored config. This preserves fields belonging to other providers while updating fields for the current provider.

   // Current behavior (replaces everything, losing other provider settings):
   const filteredConfig = discriminatedProviderSettingsWithIdSchema.parse(config)
   providerProfiles.apiConfigs[name] = { ...filteredConfig, id }
   
   // Proposed (merges, preserving other provider settings):
   const filteredConfig = discriminatedProviderSettingsWithIdSchema.parse(config)
   const existingConfig = providerProfiles.apiConfigs[name] || {}
   providerProfiles.apiConfigs[name] = { ...existingConfig, ...filteredConfig, id }

2. Leave export() behavior unchanged: The export function already intentionally strips other provider settings via the discriminated schema. This is correct for export -- you don't want to export stale credentials for unused providers.

3. Add tests: Add test cases to src/core/config/__tests__/ProviderSettingsManager.spec.ts verifying that switching providers within a profile preserves the previous provider's settings.

Why this is safe:

• Provider-specific fields (e.g., openAiBaseUrl, geminiApiKey) don't overlap between providers, so merging won't cause conflicts
• The API handler construction only uses fields relevant to the current apiProvider, so extra stored fields are ignored
• The export() function still strips other provider fields, so exports remain clean

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.