feat(settings): add Remove configuration for non-primary providers

[caezium]

Summary

There's currently no way to remove a configured provider from Settings → Providers — you can only switch which one is active. If you've experimented with multiple providers (Local, Gemini, ChatGPT/Claude) the abandoned configs, Keychain entries, and UserDefaults keys stay around indefinitely, and the only escape hatch is hand-editing.

This PR adds a Remove configuration affordance for non-primary providers, plus two safety fixes for edge cases the removal path uncovered during implementation.

1. Add Remove configuration UI (feat)

A "Remove configuration" button on each non-primary provider row in SettingsProvidersTabView, wired through a new ProvidersSettingsViewModel.removeProviderConfig(_:) which:

• Deletes Keychain entries for the provider
• Removes \(provider)SetupComplete and provider-specific UserDefaults (model id, base URL, CLI tool preference)
• Clears the backup-provider slot if this provider occupied it
• Resets in-memory @Published state so the UI reflects the cleared config immediately

canRemoveProviderConfig(_:) gates the affordance to prevent removing:

• Dayflow Pro (server-side entitlement, not local config)
• A provider that isn't configured in the first place
• The currently-active primary

2. Compare canonical provider IDs when gating removal (fix)

ChatGPT and Claude share one persisted config under the canonical id chatgpt_claude, but each surfaces as its own provider id in the routing layer. The initial guard compared raw provider IDs, which meant the chatgpt_claude config could be removed while claude (or chatgpt) was still active — bricking the provider until the user re-onboarded.

- guard primaryRoutingProviderId != providerId else { return false }
+ guard canonicalProviderId(for: primaryRoutingProviderId) != canonical else { return false }

The backup-clear branch in removeProviderConfig gets the same canonical comparison.

3. Stop UserDefaults write-back race on Local provider removal (fix)

The Local-provider branch of removeProviderConfig called UserDefaults.removeObject(forKey:) for llmLocalBaseURL, llmLocalModelId, llmLocalEngine, llmLocalAPIKey, then set the corresponding @Published properties to "". Each @Published has a didSet that writes the new value back into UserDefaults — so the removes were immediately overwritten with empty strings, leaving stale empty-string keys instead of cleared state.

Fix:

• Add a suppressLocalSettingsPersistence flag guarded inside every Local-prop didSet
• Extract resetLocalProviderFieldsAfterRemoval() which flips the flag, restores proper defaults (Ollama base URL, default model id) rather than blanks, and clears the flag in defer
• Also call LocalModelPreferences.clearPreset() so the preset selection doesn't survive removal

Test plan

• Builds (Debug, macOS arm64)
• Configure two providers, switch primary, verify "Remove configuration" appears on the non-primary row only
• Remove Gemini → Keychain entry deleted, geminiSetupComplete cleared, UI reverts to "Not configured"
• Remove Local → UserDefaults keys actually removed (no empty-string ghosts), in-memory fields reset to Ollama defaults
• Try to remove the active primary → button absent / disabled
• With Claude as primary, "Remove configuration" hidden on chatgpt_claude row until primary switches away
• With Local as backup, removing Local clears the backup slot, primary intact

[caezium]

@JerryZLiu