Support importing older-version configs by migrating on import

[mairas]

Problem

ProfileService.importProfile rejects any uploaded config whose app.configVersion is not exactly the current LATEST_APP_CONFIG_VERSION:

This configuration is version X, but this version of KIP supports version Y. Re-export it from a current KIP and try again.

So a config file exported from an older Skip (or from upstream KIP, where version-compatible) cannot be imported at all — the user must first load it into a matching-version install and re-export. As the user base grows and configs get shared across devices/versions, this becomes a real friction point.

Opportunity

The in-place upgrade path already knows how to migrate configs version-by-version: ConfigurationUpgradeService (the runUpgrade(version) dispatcher + the per-version transforms) plus the trigger in app.component. Import could route a shape-valid but older-version uploaded config through the same migration chain and then accept it, instead of hard-rejecting.

Considerations

• Import operates on an uploaded in-memory blob, not a server-stored slot, so the migration would need a path that transforms a config object directly rather than the listConfigs/getConfig/setConfig slot flow the boot-time upgrade uses.
• Decide how far back to support (min importable version) and what to do when the gap is unbridgeable.
• Security posture: running migrations over arbitrary uploaded JSON — keep the existing structural isValidConfigShape gate and bound the work.
• Storage-namespace note: Skip uses its own namespace (SERVER_CONFIG_APPID='skip', skip.* localStorage), so the legacy pre-fork (v9/v10) migration transforms are effectively dead here; an import-migration feature would realistically target the fork's own version line (currently v13) forward.

Related

• Consolidate trend charting on the SK History API; investigate whether a client-side recorder is still warranted #64 retired the recorder config model and added the v12→v13 app-config migration.