fix(server): stop probing Grok, Cursor, and OpenCode unless turned on - #7459

💭 I'm reviewing the diff scope, focusing on the changed web files and checking whether the prior flagged comment about the synthesized default-slot instance still applies given the new commit, since ProviderSettingsPanel.tsx now introduces a synthesized instance variable. Now I want to verify whether the legacy enabled flag is properly stripped and whether toggling still works correctly, so I should pull up the actual code for updateEnabled to confirm it writes to the right place. Now I'm wondering about the write path for toggling a default slot's enabled state — whether buildProviderInstanceUpdatePatch writes back into the legacy providers blob correctly. Since the synthesized instance strips enabled from config, I need to check if toggling would cause the legacy blob to lose that field when the patch writes the instance's config back. This check seems focused on UI styling consistency, but the changes here are behavioral/logic changes, not styling — though the rules do mention preserving interaction semantics, so it's also catching behavior regressions like the toggle bug flagged earlier. I want to verify the Switch toggle now works correctly for providers that default to off, so I'm checking the ProviderInstance component. I also need to check whether buildProviderInstanceUpdatePatch preserves the enabled field when writing the legacy providers blob for default instances — if it drops enabled when synthesizing the config, the toggle state could get lost and revert to false on decode. I'm tracking down that function to confirm. I'm tracing through how the default-slot update resets the legacy providers blob to driver defaults while writing the explicit providerInstances entry with enabled true, confirming the server correctly folds these into an enabled state. But I'm now second-guessing whether resetting the legacy providers entry back to its default could cause unintended side effects elsewhere. I want to check whether the registry's default-instance synthesis relies on the legacy blob's enabled flag, and whether explicit providerInstances entries properly take precedence over it in deriveProviderInstanceConfigMap and applyProviderInstanceSettings. That logic seems fine, so I should shift focus to the web side and verify the toggle behavior in ProviderInstanceCard's updateEnabled handler. I'm tracing through the default-slot toggle case: when there's no explicit instance, the synthesized config drops the enabled flag, so the envelope falls back to the legacy enabled value (false for grok). Flipping the switch on writes an explicit enabled:true into providerInstances for grok while resetting providers.grok back to its legacy default of disabled. But I need to check whether the server's derivation logic merges that legacy providers blob into the instance config for the default slot — if it does, the merged config would still carry enabled:false, which would make resolveEntryEnabled see the instance as disabled despite the toggle, so I should verify the server-side derivation function. Good, the toggle-on path checks out server side, and the Switch UI value updates correctly after enabling. The disable path for a default slot without an explicit instance also looks fine, and the dirty detection logic for the reset-to-factory flow remains unaffected. Now I'm checking a subtle web-specific issue in how provider instance settings get applied. For a default instance without an explicit entry, the enabled flag falls back correctly since the legacy blob decodes to false by default. I'm also tracing whether stripping enabled from the legacy config when synthesizing an instance could break other config-field editors — it shouldn't, since those read from instance.config directly. When a user edits a config field on a default slot, the envelope's enabled state still gets preserved correctly even though the provider config resets to default, matching the previous behavior. Since the server already folds legacy enabled flags on load, explicit instances delivered to the UI shouldn't carry stale config-level enabled values anymore, so updateEnabled writing the new enabled value directly onto the instance should be safe. I'm also confirming there's no visual or styling impact here — the changed files are purely logic, with driver lookups for default-enabled resolution and unknown/fork drivers behaving as expected. That version-skew divergence feels speculative though, more about legacy compatibility than a concrete bug. I should check whether client writes actually go through the server's fold before being reflected back, and whether other places like AddProviderInstanceDialog construct configs with an explicit enabled field that could hit the same resolution logic. I'm double-checking the toggle-on path when an explicit instance already exists without the fold, which looks fine, and confirming that resetDefaultInstance correctly disables the provider after the default-off flip, as expected. The synthesizedInstance function being called once is trivial, so I'm now considering whether there's anything else on the UI side worth checking. Tracing through the default-off switch logic confirms providers without an explicit instance correctly resolve to disabled, which is the intended behavior for the PR. I'm weighing whether an empty model picker for new users counts as a real UI consistency issue versus just the intended effect of flipping providers off by default, and checking a couple more code paths (applyProviderInstanceSettings, isModelSelectionProviderEnabled) that turn out to be either fine or out of scope — so it seems like there may be no in-scope UI findings to report, which raises a question about how to format a response when the schema expects findings but there are none. I'm now double-checking whether the toggle could still fail through another route, like an explicit instance whose config still carries enabled: false from a legacy blob that didn't get folded, or through client-side optimistic updates that might bypass server-side folding — but tracing through updateSettings confirms the patch never includes config.enabled directly, so that path looks safe too. I double-check the legacy path in applyProviderInstanceSettings and confirm it's consistent with the in-config enabled flag, so there are no UI consistency issues to flag. I'll leave the prior review thread as is and conclude with a final "all clear" response.