The v0.x config.json stored the user's model preference in a "model"
key, but the migration struct had no field for it — so every v0.x
migration silently reset the default to "deepseek-flash" regardless
of what the user had configured.

On first launch the desktop's restoreOrBuildTabs called config.Load
before MigrateLegacyIfNeeded had run — so when the config file didn't
exist yet, Load fell back to Default() (deepseek-flash). The tab's
model was resolved to Flash and saved to the tabs file before boot.Build
ran the migration and wrote the correct default_model.

Move MigrateLegacyIfNeeded to the top of restoreOrBuildTabs so it runs
once at startup, before any config loading. boot.Build's own migration
call becomes a harmless no-op (destination already exists).

…tion

Instead of writing the bare model name (e.g. "deepseek-v4-pro") to
default_model, resolve it through cfg.ResolveModel to produce a proper
"provider/model" ref (e.g. "deepseek-pro/deepseek-v4-pro"). This
makes the stored ref explicit and avoids the frontend's toRef having
to scan providers — which could pick the wrong provider if names
overlap.