fix: properly handle Gemini settings with schema-level defaults

[daniel-lxs]

Description

This PR provides a proper fix for the Gemini settings checkbox issue by addressing it at the schema/data layer rather than working around it in the UI.

Problem

When the Gemini settings checkboxes (enableUrlContext and enableGrounding) don't exist in the saved configuration, they have an undefined value. This causes the Save button to not activate when toggling these checkboxes.

Solution

This PR takes a comprehensive approach similar to commit 6aea8990:

1. Schema Changes:

   • Moves enableUrlContext and enableGrounding to the base schema as optional fields (available to all providers)
   • Makes these fields required (non-optional) for the Gemini provider specifically
   • This ensures Gemini configs always have these fields defined

2. Migration System:

   • Adds a migration to set default values (true) for existing Gemini configs
   • Cleans up these fields from non-Gemini providers where they don't belong
   • Ensures data consistency across all provider configurations

3. Data Layer Handling:

   • Updates ProviderSettingsManager to properly handle these fields
   • Ensures Gemini configs always have these fields with proper defaults
   • Removes these fields from non-Gemini providers during save/load operations

Benefits

• Root Cause Fix: Addresses the undefined state at its source rather than patching the UI
• Data Integrity: Ensures consistent data structure for Gemini configurations
• Type Safety: Better TypeScript type safety with required fields for Gemini
• Future-Proof: Any future UI components won't need special handling for undefined states
• Cleaner Code: No special case handling needed in the UI layer

Alternative Approach

This supersedes PR #6617 which attempted to fix this at the UI layer. The schema-level approach is more robust and prevents the issue from occurring in the first place.

Testing

• Existing Gemini configurations will be migrated to have these fields set to true by default
• New Gemini configurations will always have these fields defined
• The Save button now properly activates when toggling these checkboxes
• Non-Gemini providers are cleaned up to not have these irrelevant fields

Fixes #6616

---

Important

Fix Gemini settings handling by updating schema and data layer to ensure required fields are always defined for Gemini and cleaned up for non-Gemini providers.

• Schema Changes:
  • Move enableUrlContext and enableGrounding to base schema as optional fields in provider-settings.ts.
  • Make these fields required for Gemini provider in geminiSchema.
• Migration System:
  • Add migration in ProviderSettingsManager.ts to set default values for existing Gemini configs.
  • Remove these fields from non-Gemini providers.
• Data Layer Handling:
  • Update ProviderSettingsManager to ensure Gemini configs have these fields with defaults.
  • Clean up these fields from non-Gemini providers during save/load operations.

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

[roomote]

Thank you for your contribution! I've reviewed the changes and found some issues that need attention.

[roomote]

Missing test coverage for this new migration. This is a critical migration that affects data integrity and should be thoroughly tested. Could we add tests similar to the other migrations (like migrateTodoListEnabled at line 190)?

[roomote]

Is this intentional? The migration checks and updates are done separately for each flag. If an error occurs between updating the flags, it could leave the migration in an inconsistent state. Consider combining both flag updates into a single operation:

Suggested change

	if (
	if (
	!providerProfiles.migrations.enableUrlContextMigrated ||
	!providerProfiles.migrations.enableGroundingMigrated
	) {
	await this.migrateEnableUrlContextAndGrounding(providerProfiles)
	providerProfiles.migrations.enableUrlContextMigrated = true
	providerProfiles.migrations.enableGroundingMigrated = true
	isDirty = true
	}

[roomote]

The use of any type assertions here bypasses TypeScript's type checking. Could we consider using proper type guards or creating a more specific type for Gemini configurations? This would improve type safety and make the code more maintainable.

[roomote]

This logic for ensuring Gemini fields have defaults is duplicated in export (lines 536-547) and in the load method (lines 599-610). Could we extract this into a helper function to reduce duplication? Something like:

Suggested change

	if (filteredConfig.apiProvider === "gemini") {
	private ensureGeminiDefaults(config: any): void {
	if (config.apiProvider === "gemini") {
	config.enableUrlContext = config.enableUrlContext ?? true
	config.enableGrounding = config.enableGrounding ?? true
	} else {
	delete config.enableUrlContext
	delete config.enableGrounding
	}
	}

[roomote]

Good approach moving these to the base schema as optional fields! This provides flexibility while maintaining backward compatibility. The comment clearly explains the intent.

[daniel-lxs]

Closing this PR as the schema-level approach introduces TypeScript compilation issues with the cloud package. The fix needs more comprehensive testing and coordination with the types system.