fix: ProviderOnboarding: Maximum update depth loop on clean first-run profile

[yhay81]

Fixes #40.

Summary

• move preset loading out of the render path so Zustand updates cannot trigger a render loop
• guard the initial request so React StrictMode does not issue duplicate preset fetches
• add focused regression coverage for both empty and already-loaded preset state

Root cause

fetchPresets() synchronously updates the provider store before awaiting the API. Calling it while ProviderOnboarding rendered caused the store update to re-render the component and call it again indefinitely.

Validation

• bun run --cwd desktop test --run src/components/onboarding/ProviderOnboarding.test.tsx — 2 tests passed under React StrictMode
• regression discrimination — the same focused test fails to complete against the pre-fix implementation because it reproduces the render loop
• full desktop suite — PR: 742/760 passed; dev base: 740/758 passed; the same 18 pre-existing tests failed on both, with no PR-specific failures
• bun run build — passed
• bun run build:sidecars — passed on Windows x64
• bun run tauri dev with isolated CLAUDE_CONFIG_DIR and WebView2 data — advanced from Loading... to the DreamField API Key form; no Maximum update depth exceeded
• bun run lint — still fails on the unchanged dev baseline; the TypeScript error set is identical and neither changed file appears in it

Follow-up observation

The isolated profile correctly persisted dreamcoder-locale=en, but ProviderOnboarding still renders hard-coded Chinese copy. That is separate from the render-loop fix and is intentionally not mixed into this single-purpose PR; it should be tracked as a follow-up.

---

🤖 AI-authored PR, operated and verified by @yhay81.

[GoDiao]

Thanks for the focused fix. I verified the new onboarding test locally: 2 tests passed, and moving fetchPresets out of render plus the StrictMode request guard correctly addresses the render/update loop from issue #40.

One blocking concern: requestedPresetsRef.current is set to true before fetchPresets(). fetchPresets() catches request failures and only updates the store error, so after a transient preset API failure the component remains on the Loading spinner forever: it will not retry and ProviderOnboarding does not render the error. This can still make a clean first-run profile unrecoverable without restarting the app.

Please add an error state with a retry path (or reset the request guard on failure) and a regression test covering reject-then-retry/success. The existing tests cover the successful response and already-loaded presets, but not this failure path.

[yhay81]

@GoDiao Addressed in 95e29d3.