Provider-aware onboarding should make setup selections authoritative across runtime #102
Description
Summary
Provider choice during onboarding still does not fully govern the resulting runtime behavior in a trustworthy way.
Symptoms seen in the current DEV cycle:
- hidden provider defaults can still bleed into runtime startup
- setup choices can drift from actual router/runtime behavior
- older session/default state can reintroduce the wrong provider after onboarding
- users can configure one provider and still hit another provider's auth/runtime path
Issue #100 was one concrete symptom of this broader problem.
Why this matters
Onboarding should be authoritative. If a user selects a provider/model stack during setup, the runtime should honor that choice consistently.
Acceptance criteria
- onboarding selections drive chat, router, voice/search defaults, and startup behavior consistently
- hidden provider assumptions are removed from fresh setup
- missing router state no longer implies a legacy provider default
- explicit setup choices survive relaunch and update
Related
Internal tracking
WEB-112