feat: support project font persistence

[nighca]

Closes #3343

Adds Builder support for SPX project fonts:

• persist font families under assets/fonts/<family>/ and the fontPreferences array in assets/index.json;
• preserve fonts and preferences through project load/save/export;
• initialize new projects from deployment-specific default preferences, including the domestic basic-Chinese preset;
• assemble the default project from lazily loaded source assets through the project model APIs instead of an .xbp template;
• remove Builder-bundled Scratch fonts while retaining the generic SVG font-injection mechanism.

Editor previews intentionally do not consume project fonts or preferences in this PR. That integration is tracked separately in #3366 and will be implemented by #3348 after its large-font SVG rendering performance issue is resolved.

[gemini-code-assist]

Code Review

This pull request introduces support for project-specific font preferences and generic font embedding in SVGs, replacing the previous Scratch-specific implementation. It adds a new FontFamily model, updates SpxProject to manage and export font preferences, and implements a utility to inject referenced font files as base64 data URIs into SVGs. The code reviewer provided valuable feedback to improve performance and robustness: they suggested using the asynchronous FileReader.readAsDataURL API instead of a synchronous manual chunking loop to avoid blocking the main thread when encoding large font files, and recommended filtering out empty strings when parsing font preferences and extracting used font families to handle malformed inputs gracefully.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[fennoai]

Code Review Summary

This PR cleanly adds a project-font persistence layer (FontFamily model, project.fonts / fontPreferences, config round-trip, legacy-project migration) with good persistence-side test coverage, and refactors the Scratch-specific SVG font injection into a generic injectFontsToSvgText(svgText, fontPreferences, fontFiles).

The main concern is that the new mechanism is not actually wired into the runtime rendering path, which makes the feature inert at render time and regresses the previous Scratch-font embedding. A few smaller robustness/perf items follow. Security review found no exploitable issues (CSS font-family values are escaped via JSON.stringify, style is injected through XMLSerializer, and faces[].path is only used for in-memory map lookups, not filesystem access).

Inline comments cover the concrete diff-line findings. Additional items that don't map to a single changed line:

• maintainability — duplicated quote-stripping: stripQuotes in spx-gui/src/utils/svg-font.ts:9 and stripFontPreferenceQuotes in spx-gui/src/models/spx/project.ts:40 are byte-for-byte identical. Extract a single shared helper so preference parsing and SVG rule generation can't diverge on family-name semantics.
• maintainability — migration condition coupling: spx-gui/src/models/spx/project.ts:469 triggers legacy migration only when fontPreferences == null && fonts.length === 0. The null check alone is the real signal of a pre-feature project; the extra fonts.length === 0 clause is subtle and undocumented. Consider keying migration on fontPreferences == null only, or add a comment explaining why both are required.
• stale comment (outside this diff): spx-gui/src/utils/file.ts:125 still says useRenderableImageUrl "applies rendering-specific handling such as Scratch font injection for SVG files." Since scratch-svg-font.ts was removed, this should read "font injection for SVG files."
• licensing hygiene: the deleted scratch/ fonts vendored their license text (OFL.txt / LICENSE.txt), but the new basic-chinese/README.md only links to the source repo. If policy is to vendor the OFL text alongside binary font assets, consider adding it.
• test gap: spx-gui/src/utils/img-rendering.test.ts fully mocks injectFontsToSvgText, so no test asserts what arguments the real render path passes — which is why the wiring gap below is invisible to CI. Once wiring is added, assert that getRenderableImageUrl forwards the project's preferences and font files.

[nighca]

Review-summary follow-up:

• The empty-family cases and the stale useFileUrl comment were fixed in 1a0b50b.
• I kept the project-model parser and generic SVG parser local: they serve separate layers and remain small.
• I kept the migration predicate: only the absence of both preferences and collection identifies the old no-font configuration; a project already carrying fonts is not rewritten.
• The bundled Noto CJK asset is temporary and will be replaced, so we are not adding a separate license text file now.
• Project-font rendering and its end-to-end tests remain in feat: render project fonts in editor #3348, which owns editor integration and the ongoing rendering-performance work.

[nighca]

把原有的 default-project.xbp 拆了（这样方便根据不同的 env 构造不同的 project 内容），所以多了个一个新的 ‎spx-gui/src/components/project/default-project/ 目录

[nighca]

svg-font.ts 是原来的 scratch-svg-font.ts 干掉 scratch 的特有逻辑后得到的，不过它的逻辑事实上没生效，只是先保留这份逻辑，后续再更新并启用

[CORCTON]

It appears that it is possible to create font configurations that Builder accepts but SPX rejects. For example:

• A font family named DEFAULT;
• Two font families named Foo and foo;
• A preference that references a font family that does not exist in the project;
• A preference that includes both Foo and foo.

Currently, Builder only rejects empty font family names, exact matches of the lowercase name default, and cases where names are exactly duplicated, whereas SPX validates reserved names, duplicate names, and the validity of preferences after performing ASCII case conversion.

For these cases, is runtime rejection the expected behavior, or does Builder apply an equivalent validation mechanism elsewhere?

[nighca]

Currently, Builder only rejects empty font family names, exact matches of the lowercase name default, and cases where names are exactly duplicated, whereas SPX validates reserved names, duplicate names, and the validity of preferences after performing ASCII case conversion.

For these cases, is runtime rejection the expected behavior, or does Builder apply an equivalent validation mechanism elsewhere?

@CORCTON It's intended. Builder-side validation aims to enhance user experience by catching common errors and providing immediate feedback. While not replicating spx validation exactly, we focus on frequently encountered or easily verifiable mistakes to avoid unnecessary complexity.