refactor(desktop): unify API config IPC + drop separate fast model slot

[hqhq1025]

Summary

Two cleanups shipped together because they reshape the same surface area (API config / model selection):

1. Canonical IPC for API config mutations

The 3 surfaces that touch API config (top-bar pill, Settings → API 服务, onboarding) used to call 3 different IPC handlers with 3 different return shapes. The Settings 'add-provider' path returned 'ProviderRow[]' and never updated the Zustand store, so the top-bar pill could lag behind reality until a manual reload.

• New `config:v1:set-provider-and-models` handler accepts `{ provider, apiKey, modelPrimary, baseUrl?, setAsActive }`, atomically writes config, returns full `OnboardingState`.
• Existing `onboarding:save-key`, `settings:v1:add-provider`, `settings:v1:set-active-provider` are now thin delegates of the new handler — full back-compat.
• Settings → AddProviderModal calls the new handler directly + re-pulls `OnboardingState` so the top-bar pill reflects the new active provider immediately. Fixes the staleness bug.
• Preload bridge: new `window.codesign.config.setProviderAndModels()`.

2. Drop `modelFast` model slot

The `modelFast` field was used in exactly one place (`applyComment` fallback) and was indistinguishable from `modelPrimary` for users — the UI showed two near-identical dropdowns and confused everyone.

• `Config.modelFast` dropped from v2 schema. v1 configs accepted (Zod treats `modelFast` as optional; never written back).
• `OnboardingState.modelFast`, `ProviderShortlist.fast`, `ProviderShortlist.defaultFast` removed.
• `applyComment` falls back to `modelPrimary` instead.
• AddProviderModal / ChooseModel / ModelsTab UI all drop the second dropdown.
• Schema bumped: `Config.version: 1 → 2`. Migration is read-only.

PRINCIPLES §5b

• Compatibility ✅ — v1 configs read fine; legacy IPC channels still work
• Upgradeability ✅ — schemaVersion bumped, no data loss
• No bloat ✅ — net diff is -negative LOC, removes a confusing knob
• Elegance ✅ — one canonical mutation path, one model field

Test plan

• `pnpm --filter @open-codesign/desktop test` — 337 pass
• `pnpm --filter @open-codesign/desktop typecheck` — clean
• biome — clean
• DCO signed-off
• Manual: existing config.toml with `modelFast` field still loads
• Manual: add provider in Settings → top-bar pill updates without reload
• Manual: applyComment uses modelPrimary

🤖 Generated with Claude Code

[github-actions]

Findings

• [Major] Adding a provider now always flips the active provider unexpectedly — this changes runtime model/provider selection and can route subsequent generations to the wrong provider. Evidence: apps/desktop/src/renderer/src/components/Settings.tsx:334 (setAsActive: true is unconditional).
  Suggested fix:

  const onboarding = await window.codesign.onboarding.getState();
  await window.codesign.config.setProviderAndModels({
    provider: form.provider,
    apiKey: form.apiKey.trim(),
    modelPrimary: form.modelPrimary,
    ...(trimmedUrl.length > 0 ? { baseUrl: trimmedUrl } : {}),
    setAsActive: !onboarding.hasKey,
  });

• [Major] Silent fallback in Zustand sync path violates the "no silent fallbacks" constraint — failures are swallowed with no UI signal or contextual throw. Evidence: apps/desktop/src/renderer/src/components/Settings.tsx:764.
  Suggested fix:

  } catch (err) {
    pushToast({
      variant: 'error',
      title: t('settings.common.unknownError'),
      description: err instanceof Error ? err.message : String(err),
    });
  }

Summary

• Review mode: initial
• 2 issues found in modified lines: (1) active-provider behavior regression from unconditional activation on add; (2) silent error swallowing in config sync path, conflicting with project error-handling constraints.
• Not found in repo/docs: docs/VISION.md, docs/PRINCIPLES.md in this checkout.

Testing

• Not run (automation)

open-codesign Bot

[github-actions]

Unconditional setAsActive: true makes every newly-added provider become active, which changes generation routing unexpectedly. Consider deriving this from onboarding state (e.g., only true when no configured key exists).

[github-actions]

This empty catch silently swallows sync failures. The repo constraint requires surfacing every error in UI or throwing with context; please show a toast or rethrow contextualized error.

[github-actions]

Findings

• [Major] Silent fallback swallows sync failure after provider save — this violates the hard constraint that errors must surface in UI or throw with context; if onboarding:get-state fails, the code still emits a success toast and hides the failure, leaving state potentially stale. Evidence apps/desktop/src/renderer/src/components/Settings.tsx:765
  Suggested fix:

  try {
    const state = await window.codesign.onboarding.getState();
    setConfig(state);
  } catch (err) {
    pushToast({
      variant: 'error',
      title: t('settings.providers.toast.modelSaveFailed'),
      description: err instanceof Error ? err.message : t('settings.common.unknownError'),
    });
    return;
  }

Summary

• Review mode: follow-up after new commits
• 1 issue found in changed lines.

Testing

• Not run (automation)

open-codesign Bot

[github-actions]

[Major] This catch {} silently ignores failure when reloading onboarding state after save. That conflicts with the project rule that errors must surface in UI or throw with context. Consider surfacing a toast and aborting the success path so users don't get a false success state.

[github-actions]

Findings

• No actionable issues found in added/modified lines for this revision.

Summary

• Review mode: follow-up after new commits
• No new issues found in this diff.
• Not found in repo/docs: docs/VISION.md, docs/PRINCIPLES.md in this checkout. Residual risk: behavior coverage for the new canonical config:v1:set-provider-and-models path is still partial (mainly payload validation in current tests).

Testing

• Not run (automation)

open-codesign Bot