CLI hardcodes 'en' as default locale: export-seed → seed round-trip rewrites a non-'en' default locale to 'en' #1421

Summary

The seed CLI assumes the default locale is en. For any project whose configured defaultLocale is not en, an export-seed → emdash seed round-trip silently rewrites locale-bearing rows (menus, taxonomies, content) from their real default locale to en. The text is preserved but filed under the wrong locale, so the runtime's locale-scoped lookups (getMenu, taxonomy/content queries) no longer resolve it.

This is a follow-up to #1330: that fix made export-seed infer i18n from the data, but two independent en assumptions remain.

Repro

1. Project configured multi-locale with a non-en default, e.g. i18n: { defaultLocale: "de", locales: ["de", "en"] }.
2. The data currently holds a single distinct locale — the default, de. (Normal: a bilingual site that has only authored its primary locale so far, or any site that only ever uses its one default locale.)
3. emdash export-seed --with-content → the emitted menus/taxonomies/content carry no locale field.
4. emdash seed <that file> into a fresh DB.
5. Result: every row lands at locale = 'en'. getMenu("primary") under the de locale returns nothing.

Root cause — two en assumptions

1. Export omits locale for single-locale data — detectI18nEnabled (packages/core/src/cli/commands/export-seed.ts). The CLI never initializes the i18n config, so locale-awareness is inferred from the data and is true only when >1 distinct locale is present. A project that currently has data in just one locale is treated as non-i18n, so exportMenus (L469-L476) and the taxonomy/content equivalents omit locale entirely. Note this triggers even for projects configured multi-locale — it keys off how many locales the data happens to contain, not the config.

2. Apply backfills the wrong default — packages/core/src/seed/apply.ts:548 (and L227 for taxonomies):
```ts
const fallbackLocale = getI18nConfig()?.defaultLocale ?? "en";
const locale = menu.locale ?? fallbackLocale;
```
emdash seed also runs outside the Astro runtime, and the CLI does not load astro.config, so getI18nConfig() is null and fallbackLocale collapses to "en" — never the project's real default. (The _emdash_menu_items.locale column default of 'en' is the same assumption baked into the schema.)

Together: rows in a non-en default locale are exported without a locale, then re-applied as en. Only projects whose default is literally en survive the round-trip.

Why it can't simply be fixed at apply-time

The CLI has no access to defaultLocale — it does not load astro.config. So apply can't "just read the configured default." The locale has to either be carried in the seed or passed explicitly.

Suggested fixes (either/both)

• Make the seed self-describing. Have export-seed emit the actual locale even for single-locale data (don't treat "one distinct locale" as "no i18n"), or add a top-level defaultLocale to SeedFile that apply honors as the fallback.
• Let apply be told the default. Add a --default-locale flag (and/or have the runtime-driven seed path pass getI18nConfig().defaultLocale) instead of hardcoding "en".

Workaround (consumer side)

Pin locale explicitly in the seed after exporting — re-attach the data's actual locale to each menu/taxonomy/content entry that export-seed left bare.