VSF2 replaces VSF1 static config with split middleware.config.js and public runtimeConfig

A team is porting a multi-store VSF1 theme to VSF2 and must decide where each former config/default.json key belongs now that configuration is split between server middleware and public runtime config. In VSF1, one static tree was visible to both server and client and fixed at build time. VSF2 instead reads server-only values from middleware.config.js and browser-needed values from Nuxt runtimeConfig.public through useConfig.

The compatibility boundary is one-way and there is no automated migration for this split. Teams must classify every legacy setting—storeCode, currency, tax, cart settings—as either secret-server or public-runtime. Multi-store storeViews complicate the decision because the same logical value may need to exist in per-integration middleware settings and in public runtime config simultaneously. Nuxt version sensitivity adds further uncertainty, since runtimeConfig resolution differs across Nuxt 2/3 and VSF2 point releases.

For a multi-store VSF1 project, how should each legacy key be classified between middleware.config.js and runtimeConfig.public? Where should storeCode and storeViews live so SSR and hydration agree without leaking server credentials into the client bundle? How can the per-key mapping be validated against the exact pinned Nuxt and VSF2 versions before cutover?